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PREFACE 



MANUAL OBJECTIVES 

The VAX-11/RSX-llM Programmer's Reference, Manual describes VAX/VMS 
support of RSX-llM directives. This document bridges the gaps between 
the RSX-llM Executive Reference Manual and the VAX/VMS System Services 
Reference Manual ; and between the RSX-llM I/O Drivers Reference 
Manual and the VAX/VMS I/O User's Guide . 

INTENDED AUDIENCE 

This manual contains information needed by an RSX-llM programmer who 
is responsible for making RSX-llM Version 3.1 task images run under 
VAX/VMS . 

This document has two prerequisites: 

• Understanding of the RSX-llM operating system and executive 
directives 

• Understanding of the material presented in the VAX-11/RSX-llM 
User's Guide 



STRUCTURE OF THIS DOCUMENT 

Information in this document is organized as follows. 

• Chapter 1 contains a general definition of VAX-11/780 
compatibility mode and VAX/VMS support of RSX-llM Version 3.1 
images. It also contains a general description of basic 
VAX/VMS concepts, such as process and image, and their 
relationship to an RSX-llM task. 

• Chapters 2 and 3 discuss certain VAX/VMS system components and 
explain the implications of their use for RSX-llM task images. 
Chapter 3 focuses on the use of the VAX/VMS I/O system for 
RSX-llM image I/O. 

• Chapter 4 describes each RSX-llM directive as it is supported 
under VAX/VMS. 

• Chapter 5 discusses QUEUE I/O REQUEST directive function codes 
and function-dependent parameters for devices supported by 
VAX/VMS . 

• Appendix A contains the VAX-11/780 compatibility mode 
instruction set. Appendix B describes the VAX-11 RMS parse 
directive. 



IX 



ASSOCIATED DOCOHENTS 

The following documents may also be useful. 

• VAX-11 Information Directory 

• VAX/VMS Primer 

• VAX/VMS System Services Reference Manual 

• VAX/VMS I/O User's Guide 

• VAX/VMS Summary Description 

• VAX- 11/7 80 Technical Summary 

• VAX/VMS System Manager's Guide 

• VAX-11 Record Management Services Reference Manual 

• RSX-llM Version 3.1 document set 

CONVENTIONS USED IN THIS DOCUMENT 

This manual uses the same conventions as the RSX-llM Executive 
Reference Manual , for example, brackets ([]) indicate optional 
parameters. In addition, the directive descriptions in Chapter 4 use 
shading to highlight differences in VAX/VMS support of the directives . 
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CHAPTER 1 
INTRODDCTION 



Compatibility mode is a processor state that allows PDP-11 programs to 
execute under the VAX-11/780 system. For compatibility mode execution 
to occur, the needs of the program must be satisfied on two levels. 

• At the hardware instruction set level 

• At the level of program interface to the operating system 

At the hardware level, VAX-11/780 provides an instruction set that is 
a compatible subset of the PDP-11 instruction set. This compatibility 
mode instruction set provides a general basis that potentially allows 
any PDP-11 user mode program to execute using the VAX-11/780 hardware. 
In addition, VAX/VMS supplements the subset of PDP-11 instructions 
that can be used in compatibility mode through software emulation of 
the FPP floating point instructions; FIS floating point instructions 
are not emulated. 

Because of the two instruction sets, VAX-11/780 has two basic modes of 
operation: native and compatibility. The processor is in native mode 
to execute native mode instructions and in compatibility mode to 
execute compatibility mode instructions. Software controls the 
processor mode. Thus, when a non-native program has been prepared for 
execution, VAX/VMS places the processor in compatibility mode just 
before passing control to the program. VAX/VMS accomplishes this in a 
manner that is transparent to the user. 

When an RSX-llM task image executing in VAX-11/780 compatibility mode 
attempts to interface with the operating system, a hardware-generated 
trap occurs. Hardware-generated traps are the mechanism by which the 
processor notifies VAX/VMS that emulation of the RSX-llM operating 
system's environment is required. The occurrence of a compatibility 
mode trap automatically places the processor in native mode. 
Executing in native mode, VAX/VMS duplicates the RSX-llM task/system 
interface. VAX/VMS returns to the task in compatibility mode to allow 
the task to continue execution. 

For example, RSX-llM tasks use EMT377 instructions to interface with 
the operating system. An attempt to execute an EMT377 instruction on 
VAX-11/780 hardware causes a trap to VAX/VMS. VAX/VMS then emulates 
the requested service in native mode, places the processor in 
compatibility mode, and returns to the task. The task continues 
execution in compatibility mode. 

The VAX-11/780 system provides compatibility mode capabilities to 
support the migration of task images from RSX-llM operating systems to 
VAX/VMS. Compatibility mode provides a framework in which users can 
run existing task images while upgrading to take full advantage of 
VAX/VMS native capabilities. 
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INTRODUCTION 

Compatibility mode programs requiring floating point instruction 
emulation run do not run as fast under VAX/VMS as on a PDP-11. 
Compatibility mode programs not requiring floating point emulation and 
written for a PDP-11/70 run under VAX/VMS at approximately the same 
speed as they do under the system for which they were written. 
Programs not requiring floating point emulation and written for 
smaller PDP-11 processors run faster under VAX/VMS. 

For Version 1, VAX/VMS supports execution of RSX-llM Version 3.1 
nonprivileged task images in compatibility mode. The majority of 
nonprivileged, user mode RSX-llM Version 3.1 task images run under 
VAX/VMS without program modification or rebuilding. Others require 
modification. 

VAX/VMS provides the RSX-llM components (for example, MACRO-11 and 

RSX-llM task builder) needed to make required modifications using the 

VAX/VMS system as host. Modifications also can be made using an 
RSX-llM system. 

For an RSX-llM task image to execute successfully under VAX/VMS, it 
must adhere to the requirements for compatibility mode operation. 
Both the VAX-11/780 and VAX/VMS define specific requirements. These 
requirements are detailed in Sections 1.1 and 1.2. 



1.1 VAX-11/780 COMPATIBILITY WITH PDP-lls 

VAX-11/780 compatibility mode supports PDP-11 user mode operations. 
That is, any PDP-11 program that operates only in user mode (not in 
PDP-11 supervisor or kernel mode) potentially can run in VAX-11/780 
compatibility mode. Any instruction or operation denied to a user 
mode program executing on a PDP-11 is not allowed in VAX-11/780 
compatibility mode. For example, use of privileged instructions such 
as HALT and RESET is not permitted; an attempt to use a privileged 
instruction causes a trap to VAX/VMS. 

The VAX-11/780 compatibility mode instruction set also does not 
support the FIS or FPP floating point instructions; however, VAX/VMS 
emulates the FFP instructions. Appendix A of this document lists the 
VAX-11/780 compatibility mode instruction set. 

VAX/VMS places further restrictions on the use of the hardware by 
RSX-llM task images running in compatibility mode. These restrictions 
are detailed in Section 1,2. 



1.2 VAX/VMS COMPATIBILITY WITH RSX-llM VERSION 3.1 

VAX/VMS supports the capabilities of RSX-llM Version 3.1 to allow the 
execution of RSX-llM task images. However, to run in compatibility 
mode, a task image must meet the following requirements. 

• It must adhere to the hardware requirements for compatibility 
mode . 

• It must have been built by the RSX-llM Version 3.1 task 
builder. 

• It must be executable in a mapped RSX-llM system. 
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• It must not depend on environmental features of RSX-llM that 
are not available in VAX/VMS, for example, partitions, PLAS, 
or significant events. Environmental differences between 
RSX-llM and VAX/VMS are discussed further in Chapters 2 and 3 
of this document. 

• It must execute within the limitations of task/executive 
interaction described in the RSX-llM Executive Reference 
Manual . It must not be privileged for the purpose of 
overmapping the RSX-llM executive. The RSX-llM executive is 
not present in a VAX/VMS system. 

• It must not overmap the I/O page. The PDP-11 I/O page is not 
present in VAX-11/780 hardware. 

• It must not depend on the 32-word memory granularity of the 
KTll memory management unit. 

RSX-llM task images must not depend on special memory management 
features available to RSX-llM privileged tasks. Tasks can, however, 
perform privileged functions that do not involve mapping of the 
executive. For example, a task executing in compatibility mode can 
use the QIO function codes lO.RLB and lO.WLB to read directly from and 
write directly to a mounted volume if the system manager has not 
restricted the user from so doing. 

Task images that are developed under RSX-llD or IAS and that are 
compatible with RSX-llM can execute under VAX/VMS if they meet the 
requirements listed above. However, such task images must be rebuilt 
using the RSX-llM Version 3.1 task builder. RSX-llM task images do 
not have to be rebuilt to run under VAX/VMS unless program 
modification or different task builder options are required. 



1.3 RSX-llM DIRECTIVE REQUESTS 

In RSX-llM, a task image interfaces with the operating system by 
issuing directive requests. As a result of a directive request, 
RSX-llM performs the desired function and returns control to the task. 
VAX/VMS duplicates this task/system interaction. When an RSX-llM task 
image issues a directive, the hardware traps to VAX/VMS. With the 
exception of the RSX-llM memory management (PLAS) directives described 
in Section 1.4, VAX/VMS duplicates the requested RSX-llM function with 
either of the following results. 

• The RSX-llM directive function is duplicated in VAX/VMS, and 
the image continues execution. 

• VAX/VMS cannot duplicate the requested function but does take 
whatever action is necessary to allow the task to continue 
execution. 

VAX/VMS duplicates the function of the majority of RSX-llM directives. 

When VAX/VMS cannot duplicate an RSX-llM directive, it is because of 
differences in the basic concepts of the two systems, that is,' 
differences in the environments of the two systems. For example, the 
RSX-llM capability to declare a significant event does not exist in 
VAX/VMS; therefore, VAX/VMS cannot declare one upon directive 
request. Rather, it performs no operation and returns a success 
status to the requesting task image, which continues execution 
normally. 

Subsequent chapters of this document describe the details and 
implications of directive handing in VAX/VMS. 
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1.4 OVERLAYS, SHAREABLE REGIONS, HDLTIOSER TASK IMAGES, AND PLAS 

VAX/VMS supports the use of overlays produced using the overlay 
descriptor language of the RSX-llM task builder by RSX-llM images. 
VAX/VMS loads overlays from the image file at the appropriate point in 
image execution. 

VAX/VMS also supports use of shared regions by RSX-llM images. 
RSX-llM images can access both shared commons and libraries. 
Permanently available shared regions are identified to VAX/VMS by the 
system manager, as described in the VAX/VMS System Manager's Guide . 
Temporary regions are dynamically loaded when an image requiring them 
executes . 

In addition, VAX/VMS supports multiuser (shareable) task images. That 
is, when a task image is specified at task build time as consisting of 
a shareable and nonshareable portion, VAX/VMS allows multiple users to 
access the shareable portion simultaneously. Each user has a private 
copy of the nonshareable portion. 

VAX/VMS does not support the RSX-llM memory management directives that 
extend the program logical address space (PLAS) of an RSX-llM task. 
Any task image issuing a memory management directive under VAX/VMS 
receives an error status return. 



1.5 EMDLATION OF FLOATING POINT INSTRUCTIONS 

VAX/VMS provides software emulation of the PDP-11 FPP floating point 
instructions for images running in compatibility mode. The time 
required for emulation of an ADDF (register to register) or ADDF 
(memory to register) is approximately 25 that required on a PDP-11/70. 
This timing is typical of most instructions emulated. 

Results produced during emulation are the same as those produced by 
PDP-11 processors with the following two exceptions: 

1. The results of a MOD instruction are more accurate under 
emulation. 

2. On overflow, the emulator generates a reserved operand with a 
value of zero, rather than providing the residue. 

The FPP instruction set is detailed in the PDP-11/70 Processor 
Handbook . 



1.6 VAX/VMS SYSTEM CONCEPTS 

In VAX/VMS, the concept of an RSX-llM task is separated into its two 
basic components: the program image that executes, and the control 
information and virtual address space required for image execution. 
These two components correspond to the VAX/VMS concepts of image and 
process, respectively. The concepts of image and process are basic to 
VAX/VMS . 

A process is the basic schedulable program entity that the VAX-11/780 
processor executes., A process consists of a virtual address space and 
control information that both the hardware and software require, for 
example, saved register contents and status information. This control 
information is called the process context. 
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An image is the result of linking one or more object modules together. 
An image can be linked by the VAX/VMS linker to execute in native mode 
or by the RSX-llM task builder to run in compatibility mode. An image 
executes in the virtual address space provided by a process and under 
control of the process. 

A process's virtual address space is divided into two areas: the 
program region and the control region as illustrated in Figure 1-1. 
Essentially/ the program region provides virtual memory for an image. 
The control region contains information required by the system to 
control the process. 



Program Region 
RSX-11M images run in this region. 



Control Region 



231 



Figure 1-1 Process Virtual Address Space 



The concept of a process with an image is similar to the RSX-llM 
concept of task. The main difference is that a task is a form of 
process that executes a specific image while a process can execute any 
image. Furthermore, a process remains to execute subsequent images 
when the current image exits. 
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reference to an image. This is not the case with VAX/VMS; therefore, 
it is useful to state explicitly whether an operation affects a 
process or its image. For this reason, the terms process and image 
are used throughout this document instead of the term task. 



The VAX-11/780 Technical Summary further 
process and image. 



explains the concepts of 
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INTRODDCTION 

1.7 DISTINCTION BETWEEN PROGRAMMING AND SYSTEM ENVIRONMENTS 

VAX/VMS provides RSX-llM images with an environment similar to that 
provided by RSX-llM. That is, when an RSX-llM image is loaded, it has 
a virtual address space starting at location 0. It has access to a 
copy of its task header in the usual place, and RO through R7 are 
initialized as they are under RSX-llM. This environment allows the 
creation, assembly or compilation, linking, execution, and debugging 
of RSX-llM images. VAX/VMS does not, however, attempt to duplicate 
the total environment of the RSX-llM operating system. 

Certain aspects of the RSX-llM environment have direct equivalents in 
the VAX/VMS environment. An RSX-llM task name, for example, can be 
considered a VAX/VMS process name; and RSX-llM local and common event 
flags can be translated to VAX/VMS local and common event flags. 

When a VAX/VMS process executes an RSX-llM image, VAX/VMS receives the 
traps and exceptions caused by that image and interprets them as 
RSX-llM would. VAX/VMS then makes a response that is appropriate for 
the VAX/VMS environment. For example, I/O operations and 
communication with other processes (for example, SEND DATA) become 
appropriate VAX/VMS functions. 

Other aspects of RSX-llM equate to similar VAX/VMS functions. For 
example, both systems use user identification codes (UICs) . In 
RSX-llM, UICs are account (login) identifiers, provide a default user 
file directory (UDF) , and are used for file protection. In VAX/VMS, 
the concept of UIC is separated from those of account identifier and 
default directory name. Rather, the UIC concept is expanded in the 
direction of additional protection, as described in Section 2.2. 

Finally, some aspects of RSX-llM have no counterpart in VAX/VMS. 
Because no parallel function exists in VAX/VMS, VAX/VMS cannot 
translate functions associated with those concepts to VAX/VMS 
functions. Examples of RSX-llM system environment aspects not 
emulated under VAX/VMS are partitions, significant events, and a range 
of priorities from 1 through 250. Although VAX/VMS does not duplicate 
these RSX-llM features, it does accept image requests related to them 
and takes an appropriate action to allow image execution to continue. 
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CHAPTER 2 
THE VAX/VMS SYSTEM ENVIRONMENT 



The environment that VAX/VMS provides for an RSX-llM image 
determined by two factors. 



IS 



1. The privileges, UIC, and resource usage limits allotted to 
the user who initiates the image 

2. The VAX/VMS system components and conventions used to support 
RSX-llM directives requested by the image 



2 . 1 PRIVILEGES 

The system manager maintains a user authorization file that contains 
an entry for each user. That entry includes a list of the privileges 
allowed that user's process. All of the privileges that can be 
associated with a process are described in the VAX-11/RSX-llM User's 
Guide. 

VAX/VMS returns the RSX-llM DSW return code lE.PRI to an RSX-llM image 
requesting a function for which it does not have the appropriate 
privilege. The individual directive descriptions in Chapter 4 
indicate the DSW codes returned for each directive. 



2.2 UIC-BASED PROTECTION 

In VAX/VMS, each process has an associated UIC. The UIC consists of 
32 bits (1 longword) . The member code is in bits through 15 and the 
group code is in bits 16 through 31, as illustrated in Figure 2-1. 



31 




16 


15 







Group 


Member 



Figure 2-1 Format of VAX/VMS UICs 



VAX/VMS uses a process's UIC, with the privileges assigned to it by 
the system manager, to control access to the system services that 
affect other processes in the system. 

When an RSX-llM image issues a directive, VAX/VMS executes the 
corresponding system service. If this service is restricted by 
UlC-based protection in VAX/VMS, the group number and privileges of 
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the process executing the RSX-llM image are checked before the service 
is completed. An error status is returned if the issuing process is 
not in the appropriate group or does not have the appropriate 
privilege to affect the target process. ABORT TASK is an example of 
an RSX-llM directive restricted by UlC-based protection in VAX/VMS. 

VAX/VMS ignores the UIC specified when an RSX-llM image is built. 

An RSX-llM image can gain access to the UIC of its process by issuing 
a GET TASK PARAMETERS directive. The UIC is returned in two words of 
the GET TASK PARAMETERS buffer: 

• The low-order byte of the group code and the low-order byte of 
the member code are returned in word 7, as under RSX-llM: 



15 8 


7 


Bits through 7 
of group code 


Bits through 7 
of member code 



• The high-order byte of the group code and the high-order byte 
of the member code are returned in word 15: 



15 8 


7 


Bits 8 through 15 
of group code 


Bits 8 through 1 5 
of member code 



The UIC returned is for informational purposes only. The RSX-llM 
image cannot use it to affect group protection or file protection. 

An RSX-llM image cannot assume that its default account name is 
related to its UIC. VAX/VMS provides a special directive that is used 
by File Control Services (PCS) and RMS-11 to access the actual account 
name. 



2.3 RESOURCE USAGE LIMITS 

VAX/VMS controls a process's use of system resources by enforcing 
usage limits defined in the user's authorization file entry. All of 
the limits that can be defined for a process are described in the 
VAX-11/RSX-llM User's Guide . The following lists the quotas that may 
be relevant to an RSX-llM image running in VAX/VMS. 

• Number of active buffered I/O requests 

• Number of bytes of system dynamic memory used for 
buffered I/O 

• Number of active direct I/O requests 

• Number of files open simultaneously 

By default, VAX/VMS places an RSX-llM or native image that attempts to 
exceed a resource limit in a wait state until the function can be 
accomplished without exceeding the limit, for example, until other 
active I/O requests have completed. Native images can disable and 
enable resource waiting. The DCL and MCR RUN command provide an 
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option for controlling resource wait mode for subprocesses and 
detached processes. 

If an RSX-llM image attempts to exceed a limit when resource waiting 
is disabled, the image receives a DSW code of lE.UPN (insufficient 
dynamic memory) . 



2.4 PROCESS NAMES 

Each process in a VAX/VMS system has a unique 32-bit process 
identification and a process name. A process name qualified by its 
UIC is unique within a system. 

When a user initiates an RSX-llM image that has a task name in its 
image label block (that is, a task name specified at build time) , 
VAX/VMS assigns the task name as the process's name during image 
initialization. That name remains in effect until the image exits. 
Then, VAX/VMS restores the process name used prior to execution of the 
RSX-llM image. Because VAX/VMS does not incorporate the concept of an 
installed task, an RSX-llM image cannot acquire a task name by any 
means other than task building. 

An RSX-llM image must have a task name in its label block to provide a 
name for its process if any of the following is to occur: 

• The image is to receive data using the RECEIVE DATA or 
RECEIVE DATA AND EXIT directives 

• The image is to cooperate with other images using common 
event flags 

• The process containing the image is to be the target of 
directive action, for example, is to be requested or 
resumed 

The following RSX-llM directives accept a task name as an argument. 

• ABORT TASK 

• CANCEL TIME BASED INITIATION REQUESTS 

• REQUEST 

• RESUME 

• RUN 

• SEND DATA 

VAX/VMS supports the RSX-llM convention of naming multiuser MCR tasks 
with a string that starts with three periods, for example, ...PIP. 

When VAX/VMS encounters an image with a task name of this type, it 

recognizes that the image can be run by more than one user 

simultaneously. For such images, VAX/VMS does not create a process 

name from the task name or set up the mechanisms for it to receive 

data from other processes and to synchronize with other processes 
using common event flags. 
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2.4.1 Native Mode Considerations 

If an RSX-llM image is to issue directives that specify a process 
executing a native image as the target, the user must be aware of the 
difference in the allowable lengths of task names and process names. 

A task name has a maximum length of six characters. A process name 
has a maximum length of 15 characters. Therefore, if an RSX-llM image 
is to refer to a process running a native image, that process's name 
must not exceed six characters. An RSX-llM image cannot express a 
process name that exceeds six characters. 

A process running a native image can create a subprocess or a detached 
process, assign it a process name, and designate an image that the 
process is to execute. Thus, a process can create a named subprocess 
or detached process that executes an RSX-llM image. Once the process 
is created, other processes can issue system service requests in 
native mode or directive requests in compatibility mode that designate 
the process as the target. The creator of a subprocess always is 
allowed to affect the subprocess. Other processes and subprocesses 
must have either group or world privilege to affect the subprocess. 

Subprocess and detached process creation are described in the VAX/VMS 
System Services Reference Manual . 



2.5 EVENT FLAG CLUSTERS 

In VAX/VMS, event flags are contained in clusters of 32 flags each. A 
process automatically has two local event flag clusters and, 
optionally, can associate with up to two common event flag clusters. 

VAX/VMS does not provide a single system-wide set of common event 
flags. Instead, it creates common event flag clusters dynamically. 
Each cluster can be shared among processes wishing to communicate by 
means of event flags. 

Access to common event flags in VAX/VMS is protected using UICs. This 
fact has an operational implication: processes executing RSX-llM 
images that are to cooperate using common event flags must run in the 
same group. 

VAX/VMS emulates both local and common RSX-llM event flags to provide 
the event flag capability of RSX-llM. RSX-llM images need not make 
any allowance for VAX/VMS handling of event flags. 

When VAX/VMS loads an RSX-llM image into memory, it checks the task 
image label block for a task name. If it finds one, just prior to 
actual image execution, VAX/VMS creates a common event flag cluster 
named RSXCOMEFN and associates the process with it. If no task name 
was specified when the image was built or if the task name is in the 
form ...XXX, VAX/VMS does not allow the image to use common event 
flags. 

If a subsequent RSX-llM image in another process meets the 
requirements for common event flags and is loaded, VAX/VMS compares 
group numbers. If the group numbers are the same, VAX/VMS associates 
the process with the existing common event flag cluster. If the 
numbers are different, VAX/VMS creates another common event flag 
cluster named RSXCOMEFN qualified by that group number and associates 
that process with it. 
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None of the event flags to which an RSX-llM image has access is 
reserved for VAX/VMS system use. 

Any image, regardless of the presence, absence, or type of task name, 
can use local event flags. 

Figure 2-2 illustrates the common clusters created for the following 
processes that communicate using event flag clusters. 

• PROCA, PROCB, and PROCC running in group 200 

• PROCD and PROCE running in group 300 

VAX/VMS creates two event flag clusters: one for processes in group 
200 and one for processes in group 300. 



[200,25] PROCA - 
[200,27] PROCB - 
[200,28] PROCe - 
[300,41] PROCD - 
[300,45] PROCE - 



[200] 

RSXCOMEFN 

(32 flags) 



[300] 

RSXCOMEFN 

(32 flags) 



Figure 2-2 Group Association of Common Event Flag Clusters 



2.5.1 Native Mode Considerations 

Native images can interact with RSX-llM images using event flags. 
However, the native image must consider the treatment of the RSX-llM 
image by VAX/VMS. Use of event flags for native mode images is 
detailed in the VAX/VMS System Services Reference Manual . 

A native mode image written to interact with a compatibility mode 
image using common event flags needs to be aware of the flag number 
conversion performed by VAX/VMS. 

For a process running an RSX-llM image, VAX/VMS uses the first three 
clusters, as follows: 

• Cluster (flags through ii) is reserved for system use in 
coordinating compatibility mode activities for the process 

• Cluster 1 (flags 32 through 63) is the process's local event 
flag cluster , 

• Cluster 2 (flags 64 through 95) is the process's common event 
flag cluster 
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VAX/VMS converts RSX-llM local event flag numbers 1 through 32 to 
VAX/VMS event flag numbers 32 through 63. It converts the RSX-llM 
common event flag numbers 33 through 64 to VAX/VMS event flag numbers 
64 through 95. 

Each process using common event flags must associate with the common 
event flag cluster containing the flags. For RSX-llM images, VAX/VMS 
automatically associates the process with a cluster named RSXCOMEFN if 
the image has a task name; see Section 2.4, "Process Names." Any 
process executing a native image that wants to use flags in RSXCOMEFN 
must first associate with that cluster. 

The process executing the native image must be in the same group as 
other processes using the common cluster. 



2.6 SYSTEM STATUS CODES 

In VAX/VMS, the symbolic name for a system service status return has 
the following format. 

SS$_name 

When an image issues an RSX-llM directive, VAX/VMS attempts to emulate 
the desired function and then returns a DSW code to indicate success 
or failure to the image. In most cases, VAX/VMS calls the system 
service that performs the equivalent of the requested RSX-llM function 
and converts the status code returned by the service to the equivalent 
RSX-llM DSW code. For example, the VAX/VMS code SS$ NORMAL becomes 
DSW code IS. sue. 

In some cases, however, a directive request results in a VAX/VMS error 
for which no exact RSX-llM equivalent exists. This situation occurs 
when an image attempts to violate a VAX/VMS concept that has no 
RSX-llM equivalent. VAX/VMS handles the situation in one of the 
following ways. 

• By returning a default DSW code 

• By returning a DSW code that is meaningful for the error but 
that could not be returned for the directive when running 
under RSX-llM 

Default return codes are used when no clear one-to-one relationship 
exists between VAX/VMS and RSX-llM codes; for example, a VAX/VMS code 
that is equally related to two DSW codes. 

A new DSW code is returned when a VAX/VMS error has no counterpart in 
RSX-llM. An example is lE.PRI which indicates that the image 
attempted to issue a directive for which its process does not have the 
appropriate privilege. For example, the image attempted to resume 
another process in its group but does not have group privilege. 

In some cases after a directive failure, VAX/VMS returns an error code 
in the DSW that is more meaningful to I/O operations. In these cases, 
the high-order byte of the DSW contains 0. The DSW codes lE.PRI and 
IE. DUN (for ASSIGN LUN) are examples of codes that are returned as 
bytes rather than words. RSX-llM images can determine whether a DSW 
code is returned as a byte or word by testing the high-order byte of 
the DSW for 0. 

DSW codes that can be returned for each directive are listed in 
Chapter 4 with the individual directive descriptions. 
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2.7 MEMORY MANAGEMENT 

VAX/VMS memory management facilities control the use of physical 
memory and virtual memory. VAX/VMS controls the use of physical 
memory by processes through implementation of two system concepts. 

• Balance sets and swapping 

• Working sets and paging 

The VAX/VMS Summary Description details these concepts. 



2.7.1 Swapping 

The swapper determines which processes reside in main memory. All the 
resident processes are referred to as the balance set. Processes in 
the balance set compete for access to the central processor. 

VAX/VMS swaps processes from and to main memory to ensure that the 
highest priority processes are always available in memory for 
execution. The VAX/VMS swapper is considerably more sophisticated 
than the RSX-llM checkpointing function. It does, however, provide an 
equivalent mechanism to allow emulation of the RSX-llM ENABLE 
CHECKPOINTING and DISABLE CHECKPOINTING directives. 

The initial state of an RSX-llM image in a process is to have swapping 
(checkpointing) enabled. This state is identical to the initial state 
of an image under RSX-llM. An RSX-llM image that wants to use the 
DISABLE CHECKPOINTING directive must have the VAX/VMS privilege to set 
its swapping mode. 

Because VAX/VMS controls the use of physical memory by swapping 
processes out of and into a balance set, it does not support 
partitioning of physical memory. As a result, when an RSX-llM image 
issues a GET PARTITION PARAMETERS directive, VAX/VMS returns a 
standard response for a system-controlled partition named GEN. The 
exact content of the information returned is described in Section 
4.3.19. 

VAX/VMS ignores the partition name in the image label block. 



2.7.2 Paging 

The virtual address space for a process consists of a number of 
512-byte pages. VAX/VMS, under control of the system manager, assigns 
each process a limited number of pages of physical memory that the 
process can use when it is in the balance set. That limit is referred 
to as the process's working set. Normally, a process is allowed a 

gi.eatei. nuiiibei. Of vlLCudl pdyeS than physlcdl peiijfis . The VAX/VMS 

pager determines the pages of a process's virtual address space that 

are in physical memory (that is, in the working set) at any instance 
during process execution. 

VAX/VMS facilities for control of a process's virtual address space 
differ significantly from the RSX-llM approach to a task's virtual 
memory. As a result, VAX/VMS does not support the RSX-llM memory 
management (PLAS) directives. 

Every RSX-llM image has 65K bytes of virtual memory available to it. 
Because the address space is virtual rather than physical, RSX-llM 
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images can avoid overlaying; an image executes more efficiently by 
depending on VAX/VMS memory management to determine which pages are 
needed in physical memory and when they are needed. Further 
efficiency can be gained by building RSX-llM images as shareable 
(/MU) . So doing results in RSX-llM images that can be partially 
shared under VAX/VMS. 



2.8 SYSTEM EVENTS 

A system event in VAX/VMS is an occurrence that favorably or adversely 
affects the ability of one or more processes in the system to execute. 
For example, an executing process can put itself in a wait state, or 
it can set an event flag that makes another process a candidate for 
execution. System events are similar in concept to RSX-llM 
significant events. In VAX/VMS, however, an image cannot request the 
declaration of a system event. No VAX/VMS equivalent for the DECLARE 
SIGNIFICANT EVENT and WAIT FOR SIGNIFICANT EVENT directives exists. 
Issuing either of these directives has no effect on VAX/VMS; success 
status is returned to the issuing image. 



2.9 SYSTEM CLOCK 

On PDP-11 systems, the number of ticks per second varies depending on 
the type of clock used and its frequency. For the time-related 
directives, VAX/VMS emulates a . 100-tick-per-second clock. This 
difference may affect emulation of the following directives, which 
have time-oriented arguments. 

• MARK TIME 

• RUN 

• GET TIME PARAMETERS 



2.10 SOFTWARE PRIORITIES 

VAX/VMS priorities range from through 15 for normal processes and 
from 16 through 31 for time-critical (real-time) processes. For 
further details on VAX/VMS handling of priorities, see the VAX/VMS 
Summary Description . 

Because RSX-llM process priorities do not correspond to VAX/VMS 
priorities in a meaningful fashion, VAX/VMS does not attempt to 
convert a task's priority, as specified in the image's task header, to 
a VAX/VMS priority. 

An RSX-llM image runs at a priority that is determined by the default 
priority in the user authorization file entry for the user initiating 
the process. When an image issues an ALTER PRIORITY directive, 
VAX/VMS performs no operation, and image execution continues at the 
original process priority. An image requiring high priority must 
execute in a process that has sufficiently high priority to meet the 
image's needs. 
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2.11 GLOBAL SECTIONS 

In VAX/VMS, global sections are disk files containing data or code 
that can be brought into memory and made available to processes for 
manipulation and execution. Global sections are created by executing 
images and by the system manager. 

When a global section is created, its creator assigns a set of 
characteristics to it. A global section can have the following 
characteristics. 

• Read-only or read/write 

• Temporary or permanent 

• Group or system wide 

A temporary global section remains in the system only as long as 
processes are mapped to it; when no processes are mapped to it, 
VAX/VMS deletes it automatically. A permanent global section remains - 
in the system until it is explicitly deleted. 

VAX/VMS provides group protection for group global sections. Any 
process can gain access to a system global section. A process must be 
privileged to create a permanent or system global section. 

VAX/VMS imposes no limit on the number of global sections to which a 
process can map. 

When VAX/VMS loads an RSX-llM image that was task built specifying one 

of the options COMMON, LIBR, RESCOM, or RESLIB, it sets up the 

specified library or common for the image. When VAX/VMS loads the 

RSX-llM image, it determines whether the global section for the 
library or common already exists. 

If the global section exists, it is either of the following. 

• A permanent global section created by the system manager 

• A temporary global section created by VAX/VMS as a result of 
previous RSX-llM image execution 

In either case, VAX/VMS maps the RSX-llM image to the global section. 

If the global section does not exist, VAX/VMS creates a temporary 
group global section for the library or common specified in the 
COMMON, LIBR, RESCOM, or RESLIB option to the task builder. The image 
file for either the library or common must be located on logical 
device and directory SYS$LIBRARY. 

When VAX/VMS creates a global section for use by RSX-llM images, the 
section has the following characteristics. 

• Global sections are accessed as either read-only or 
read/write, and either position dependent or position 
independent, according to the task builder specification. 

• Global sections are group and temporary. 

• The global section name is either the library name specified 
in a COMMON or LIBR option or the file name specified in a 
RESCOM or RESLIB option. 
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The disk file for a read/write global section is updated to reflect 
data manipulation by processes that map to it. 

VAX/VMS does not incorporate the concept of an installed global 
section that can be re-installed to obtain a fresh copy. The disk 
file for a read/write global section is updated to reflect data 
written in the global section. Therefore, if it is necessary to 
maintain the original state of a read/write (common) global section, 
the user must keep a protected copy of the common file in a place 
other than SYS$LIBRARY. 

If the library or common area referred to is not found, VAX/VMS prints 
an error message on SYS$ERROR specifying the name of the library or 
common. 



2.12 HIBERNATION 

VAX/VMS defines a process state called hibernation in which a process 
can remain in the system but be inactive. A hibernating process in 
VAX/VMS is equivalent to a suspended task in RSX-llM; that is, both 
can be reactivated by the following: 

• A programmed request for activation (Wake system service 
or RESUME directive) 

• Delivery of an AST 

Hibernating processes are quickly reactivated under VAX/VMS. 

VAX/VMS also uses the Wake system service in the emulation of RUN and 
REQUEST directives. As a result, the target of either directive must 
be a hibernating process or one that is active in the system. 

Both the DCL and MCR RUN commands provide the means of creating a 
subprocess or detached process to execute a specified image, 
scheduling the process for a future time, and placing that process in 
hibernation before execution. 

Before placing the process in hibernation, VAX/VMS loads the image, 
performs the device assignment for any preassigned devices, and loads 
any libraries or common areas, if needed. 



2.13 IMAGE TERMINATION 

Any image running in VAX/VMS can terminate normally or abnormally. 
Normal termination occurs when the image terminates of its own accord. 
Abnormal termination occurs when the system or another process forces 
the image to exit. 



2.13.1 Normal Termination 

When an RSX-llM image terminates normally, VAX/VMS performs the same 
image cleanup operations as it does for a native image. If an RSX-llM 
image issues a TASK EXIT directive, VAX/VMS executes an Exit system 
service, and returns the termination status of SS$_NORMAL. RSX-llM 
images also can issue an EXIT WITH STATUS directive to specify the 
appropriate status. 
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For both VAX/VMS and RSX-llM images, the termination status is 
available to the command interpreter. Both the DCL and MCR command 
interpreters use the termination status when processing indirect 
files. DCL uses the termination status with the ON command for error 
handling. MCR uses the status with .ONERR handling. The 
VAX-11/RSX-llM User's Guide describes the use of indirect command 
files with the MCR command interpreter. The VAX/VMS Command Language 
User's Guide describes the use of DCL command procedures (indirect 
command files) . 



2.13.2 Abnormal Termination 

When a VAX/VMS image incurs a potentially fatal error condition, 
either of the following can occur. 

• The image can handle the condition 

• VAX/VMS forces the image to terminate 

VAX/VMS images can react to fatal errors using the VAX/VMS condition 
handling mechanism. Through that mechanism, an image can provide one 
or more condition handling routines that are to be executed to handle 
an error (exception) condition. The condition handling mechanism 
provides a function that is comparable to, but considerably more 
flexible than, the RSX-llM synchronous system trap (SST) mechanism. 
VAX/VMS condition handling is described in the VAX/VMS System Services 
Reference Manual . 

If an image incurring a condition handles it, the image can continue 
execution or exit normally, as described above. If the image does not 
handle the condition, the system terminates the image by issuing an 
Exit system service. The Exit system service initiates image-related 
cleanup operations and saves the termination status. That status is 
available to the command interpreter or the next image to execute in 
the process. 

Abnormal termination of an RSX-llM image can occur as a result of any 
of the following: 

• Violation of the hardware conventions for images running 
in compatibility mode 

• Issuance of an instruction, other than EMT377, that causes 
a trap 

• Use of an illegal JMP or JSR instruction format 

• Occurrence of an odd address error 

• Violation of memory protection 

• Request for an abort from another process 

• Attempt to exceed virtual memory usage limits 

An RSX-llM image can supply a synchronous system trap (SST) service 
routine to handle some of the errors listed above. If the address of 
an SST service routine for an error is supplied in the SST vector 
table and that error occurs, VAX/VMS continues image execution in the 
SST routine. The routine determines whether the image is to exit or 
continue. If no SST address if supplied, VAX/VMS terminates the 
image . 
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If the error is one that cannot be handled by an SST service routine 
or if no valid SST routine address is supplied, VAX/VMS issues a 
termination message on the device assigned to SyS$ERROR and 
SYS$OUTPUT. VAX/VMS causes the image to exit with a termination 
status that is available to the command interpreter. 

Table 2-1 lists the reasons for image termination and indicates which 
errors can be handled by an SST service routine. The status codes in 
parentheses following the termination messages are defined by $RSXDEF 
macro. 
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2.14 PARSING OF FILE SPECIFICATIONS 

Because of the VAX/VMS logical name capability, VAX/VMS file 
specifications can differ from those used in RSX-llM. The normal 
RSX-llM parsing routines cannot provide defaults for such VAX/VMS file 
specifications. VAX/VMS provides a special directive that is issued 
by FCS and RMS-11 running under VAX/VMS so that they provide proper 
defaults in a manner that is transparent to the RSX-llM image. Any 
RSX-llM image that performs its own parsing also must call this 
special directive, as described in Appendix B. 

An RSX-llM image issuing such a directive uses the same sources for 
default information as it does under RSX-llM, for example, the default 
file name block and directory string. When the directive is issued, 
VAX/VMS builds the necessary RMS data structures and calls VAX-11 RMS. 
When VAX-11 RMS returns the expanded file specification, VAX/VMS 
returns it to the image in the format used by FCS and RMS-11, for 
example, in the resultant file name block and directory string. 



2.15 VAX/VMS I/O SYSTEM 

VAX/VMS uses its own I/O system in duplicating RSX-llM I/O operations. 
Components at all levels of the VAX/VMS I/O system provide functions 
that are similar to equivalent functions in RSX-llM. For example, 
VAX/VMS I/O system services provide functions similar to those 
provided by RSX-llM I/O directives. Differences between the two I/O 
systems arise in either of the following cases: 

• VAX/VMS implementation of a function varies from RSX-llM 
implementation to provide more flexibility or 
efficiency, for example, certain Queue I/O Request 
function codes 

• VAX/VMS implementation of a function or concept not 
provided in RSX-llM and use of that function in 
emulating RSX-llM I/O 

Such differences affect emulation of the following I/0-related 
directives. 

• ASSIGN LUN 

• GET LUN INFORMATION 

• QUEUE I/O REQUEST 

• QUEUE I/O REQUEST AND WAIT 

• SEND DATA 

• RECEIVE DATA 

• RECEIVE DATA OR EXIT 

Chapter 3 presents an overview of the VAX/VMS I/O system and relates 
aspects of it to an RSX-llM image. 
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CHAPTER 3 
VAX/VMS I/O SYSTEM 



Components of the VAX/VMS I/O system range in orientation from 
user-level I/O requests to device-level I/O drivers. The I/O system 
comprises the following components. 

• VAX-11 RMS for user-level, device-independent I/O 

• I/O system services that provide the means for an image 
to assign devices and issue I/O requests directly 

• Ancillary control processes (ACPs) for performing 
file-oriented functions on disk and magnetic tape 
volumes 

• I/O drivers 

Figure 3-1 illustrates the relationship among these components. 



3.1 VAX-11 RMS 

VAX/VMS record management services (VAX-11 RMS) provide native VAX/VMS 
images with the capability to perform device-independent I/O. Images 
issue commands to open a file, get and put records or read and write 
blocks, and close the file. VAX-11 RMS, in turn, issues the I/O 
system services that cause the driver or ACP to perform the function 
requested by the user. 

VAX-11 RMS is the VAX/VMS equivalent to FCS and RMS-11. It has no 
direct effect on and is inaccessible to an RSX-llM image executing in 
compatibility mode. VAX/VMS does, however, call VAX-11 RMS to perform 
some I/O services on behalf of an RSX-llM image. 

VAX-11 RMS is described in the VAX-11 Record Management Services 
Reference Manual. 
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VAX/VMS 
image 



VAX-11 
RMS 



I/O system services 



I/O drivers 



Peripheral 
devices 



ACPs 



Figure 3-1 Components of VAX/VMS I/O System 



3.2 VAX/VMS I/O SYSTEM SERVICES 

A native image can call VAX/VMS I/O system services to describe its 
I/O requirements directly, that is, without using VAX-11 RMS. The 
request can be issued by a user image or by VAX-11 RMS on behalf of a 
user image. I/O services allow a suitably privileged process to 
request the following functions: 

Assign a channel to a device and later deassign it 

Queue an I/O request and, optionally, wait for its 
completion 

Create a mailbox and later delete it 

Allocate a device and later deallocate it 

Get information about a device 

Cancel I/O on a channel 
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3.2.1 Assign I/O Channel System Service 

Before a VAX/VMS image can request an I/O operation, it must establish 
a path of reference from the process in which it is executing to the 
device on which the operation is to be performed. In VAX/VMS, this 
path of reference is obtained by calling the Assign I/O Channel system 
service. This service returns a channel number (path designator) for 
the assigned device. The channel number remains valid until the image 
deassigns the channel or terminates. 

In addition to the channels assigned by an image, a process has 
channels assigned by the system. These channels are permanent for the 
duration of the process. They provide the path of reference for the 
process-permanent files used for system input (SYS$INPUT and 
SYS$COMMAND) , system output (SYS$OUTPUT) , error messages (SYS$ERROR) , 
and any user-created process-permanent files. For RSX-llM images 
under VAX/VMS, user-created process-permanent files appear as 
record-oriented terminal devices. 

An image can request I/O operations on channels that it assigns and on 
those that the system assigns to process-permanent files. However, 
VAX-11 RMS must be used for I/O operations to process-permanent files 
except those mapping to terminal devices. The Assign I/O Channel 
system service is the VAX/VMS equivalent of the ASSIGN LUN directive. 



3.2.2 Queue I/O Request System Service 

Once the image has assigned a channel to a device, the image can 
request I/O operations by calling the Queue I/O Request system service 
and specifying the channel number returned by the Assign I/O Channel 
service as an argument. Additional arguments provide 
function-dependent and function-independent data required for the I/O 
operation. 

When called, the Queue I/O Request system service allocates and^^uilds 
an I/O request packet that describes the operation to be performed as 
indicated by the arguments passed to it by the image. Once the packet 
is built, the Queue I/O Request system service places the packet in a 
queue of requests for the designated device. Requests are queued 
according to the priority of the process from which the image issued 
the request. The driver for the device unit dequeues requests by 
priority and performs them. 



3.2.3 Create Mailbox and Assign I/O Channel System Service 

The Create Mailbox and Assign I/O Channel system service lets an image 
create a virtual device, called a mailbox, and assign an I/O channel 
to it. Mailboxes provide the mechanism for protected interprocess 

COuimUniCa^lOri in vn^/ wxtj, NoriTiaj-xy, art irua^c Ci^cat^S a maxj.OOX xirOIit 

which it reads and to which other images in cooperating processes 
write. Access to the mailbox is restricted using the normal UlC-based 
protection according to system, owner, group, and world. An image 
performs I/O operations on a mailbox using VAX-11 RMS $GET and $PUT 
commands or the Queue I/O Request system service. 

A mailbox has no RSX-llM equivalent. However, VAX/VMS does use 
mailboxes in duplicating RSX-llM send/receive directives. If a 
logical name is assigned to an existing mailbox, an RSX-llM image can 
issue I/O requests to the mailbox using the mailbox's logical name. 
An RSX-llM image cannot create a mailbox directly. Use of mailboxes 
for send/receive directives is detailed in Section 3.8.1, "Mailboxes 
for Send/Receive Directives." 
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3.2.4 Additional I/O System Services 

The Allocate Device system service lets an image reserve a device for 
exclusive use by the process in which the image is executing. The 
device remains allocated until it is explicitly deallocated or until 
the process terminates. VAX/VMS automatically allocates any 
nonshareable device (for example, terminal or card reader) assigned by 
a process. It does not automatically allocate a shareable device (for 
example, disk) . The concept of device allocation is the VAX/VMS 
equivalent to the RSX-llM concept of attaching a device. 

The Get Device Information system service lets an image obtain the 
name and characteristics of the device assigned to a particular 
channel. It is equivalent to the GET LUN INFORMATION directive in 
RSX-llM. 

The Cancel I/O Request system service lets an image cancel all I/O 
requests pending on the specified channel. It is equivalent to the 
RSX-llM QUEUE I/O REQUEST directive with a function code of lO.KIL. 

I/O system services are described in the VAX/VMS System Services 
Reference Manual. 



3.3 I/O DRIVERS AND ACPS 

Using information in the I/O request packet, the I/O driver for the 
unit to which the request was queued initiates the actual hardware 
operation that performs the requested function. Once the transfer is 
initiated, the driver returns control to the Queue I/O Request system 
service. The service returns the request status to its caller. When 
the hardware operation completes, the hardware generates an interrupt 
that causes the driver to be re-entered to 6omplete processing of the 
I/O request. 

When the driver completes the I/O request, it issues a software 
interrupt for the I/O post routine. The I/O post routine sets up the 
mechanism that causes user-requested I/O completion information to be 
passed to the image. For example, it fills in the I/O status block 
and passes information needed to set an event flag or queue an AST, if 
either is requested. 

If the driver cannot perform the request because it requires 
understanding of file-structured volumes, ACP intervention is needed. 
In that case, the driver queues the request for the appropriate ACP to 
perform. 



3.4 RSX-llM IMAGE INTERFACE TO THE VAX/VMS I/O System 

RSX-llM images perform I/O by issuing requests at the FCS/RMS-11 level 
or the QIO$ directive level. The number of steps required to perform 
each I/O operation varies depending on the level of the request. 
Figure 3-2 illustrates the interface between an RSX-llM image and the 
VAX/VMS I/O system. 
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RSX-11M image issues 
FCSor RMS- 11 request 



Request goes to FCS or 
RI\flS-1 1 running in 
compatibility mode 



FCSeSr RMS- 11 issues 
the appropriate QIO$ 



OR 



RSX-1 1M image issues QIO$ 



QIO$ traps to VAX/VMS 




VAX/VMS issues 
appropriate $QIO 



VAX/VMS converts status 

code returned to 

appropriate DSW code 



VAX/VMS returns DSW code 
to image issuing QIO$ 



Driver notifies VAX/VMS 
of I/O completion 



VAA/VMb converts lUSH 

status and returns status, 

if lOSB is defined 



VAX/VMS issues 1/0 done 

AST for image and/or sets 

event flag, if requested 



VAX/VMS issues 
VAX-1 1 RMS $GET or $PUT 



VAX-1 1 RMS issues 
appropriate $010 



Figure 3-2 RSX-llM Image Interface to VAX/VMS I/O System 
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Images issuing FCS and RMS-11 requests use the same PCS and RMS-11 
routines available in RSX-llM.l Some of these routines have been 
modified to take advantage of VAX/VMS features, for example, parsing 
of file specifications that use the VAX/VMS logical name facility. To 
take advantage of the modifications, the RSX-llM image must be rebuilt 
under VAX/VMS. The VAX/VMS modifications are compatible with RSX-llM 
versions of FCS and RMS-11. 

Both FCS and RMS-11 run in compatibility mode under VAX/VMS. When an 
RSX-llM image issues either an FCS or RMS-11 request, FCS or RMS-11 
receives the request and reacts to it in the same mannner as it does 
when running in RSX-llM. That is, FCS/RMS-1-1 issues the appropriate 
RSX-llM QIO$ directive. 

From this point, the steps involved are identical to those when any 
RSX-llM image issues a QIO$ directive: 

• The QIO$ directive traps to VAX/VMS. 

• VAX/VMS determines whether the QIO$ was to a process-permanent 
file, for example, TI or SYS$OUTPUT. If it is and that device 
is not a terminal, VAX/VMS issues a VAX-11 RMS $GET or $PUT 
request. Otherwise, VAX/VMS issues the VAX/VMS $QIO system 
service request that corresponds to the RSX-llM QIO$. 



• Upon completion of the QIO request, VAX/VMS 
appropriate DSW code to the issuing image. 



returns the 



• Upon completion of the I/O operation, VAX/VMS returns status 
information in the I/O status block and sets an event flag or 
declares an AST, if requested. 

If the routine to which the DSW code is returned is either FCS or 
RMS-11, that component in turn makes the appropriate status return to 
the calling image. 



3.5 DEVICE ASSIGNMENT 

VAX/VMS performs device assignment for RSX-llM images as part of image 
initialization when the image is loaded. It also performs device 
assignment during image execution as a result of an ASSIGN LUN 
directive. 

In making a device assignment for an RSX-llM image, VAX/VMS proceeds 
with the following steps, which result in the device unit's physical 
name. 

• VAX/VMS forms an ASCII string using the device name and unit 
number supplied by the image. VAX/VMS uses the two characters 
plus the binary unit number supplied. The unit number is 
converted to ASCII base 8. No editing is performed on the 
name; for example, if TTl is supplied, that name is used 
rather than TTOl. 



1. Because the VAX/VMS Files-11 ACP does not support block locking, 
RMS-11 block locking across processes is not supported. As a result, 
RMS-11 does not allow file sharing for wr ite-accessed files of 
relative and indexed organization under VAX/VMS. 
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• VAX/VMS attempts to translate the ASCII string as a logical 
name using the Translate Logical Name system service. If the 
attempt to translate fails, VAX/VMS assumes that the image 
supplied an RSX-llM physical device name. It converts the 
unit number to decimal. It builds a VAX/VMS physical device 
name using the image's original input and issues an Assign I/O 
Channel system service using the VAX/VMS device name. VAX/VMS 
maps RSX-llM physical device names to VAX/VMS physical device 
names, as described in Section 3.6. 

If the name translates, VAX/VMS attempts up to two more 
translations. If the maximum number of translations (three) 
is performed or if one of the attempts results in no 
translation, VAX/VMS assigns a channel using the final 
equivalence name. 

For example, if INO is defined as a process's logical name for TTB3 
and that process runs an RSX-llM image which subsequently issues an 
ASSIGN LUN directive for INO, VAX/VMS forms an ASCII string for INO, 
translates the string to TTB3, and then assigns a channel to TTB3 . 



3.6 DEVICE MAPPING 

If the user does not assign the RSX-llM device name as the logical 
name for a VAX/VMS physical device unit, VAX/VMS automatically 
performs the translation to a physical device by converting the 
RSX-llM unit number to decimal and dividing it by 16 (decimal). The 
quotient is added to the ASCII value representing the character A 
(65). The result is the controller letter. The remainder becomes the 
VAX/VMS unit number. For example, RSX-llM devices TTO and DB18 become 
VAX/VMS devices TTAO and DBB2, respectively. 

TTO to TTAO; 

Controller and unit =A+0_=A+0 with a remainder of 

16 

A + = 65 = controller 
= unit number 

DB18 to DBB2: 

Controller and unit =A+18 =A+1 with a remainder of 2 

16 

A + 1 = 66 = B = controller 
2 = unit number 



VAX/VMS performs this conversion when assigning an I/O device 
RSX-llM image. 



for 



an 



To convert back from a VAX/VMS device name to the RSX-llM form, 
VAX/VMS performs the reverse operation. It subtracts the value 
representing the ASCII character A (65) from the controller letter and 
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multiplies the result by 16 (decimal). It then adds the VAX/VMS unit 
number. The result is an RSX-llM unit number that is appended to the 
2-character device name. For example, the VAX/VMS device name LPBl 
converts to the RSX-llM device name LP17. 

LPBl to LP17: 

Unit =((B, - A) * 16) + 1 = (1 * 16) + 1 = 17 

VAX/VMS performs this conversion and stores it in the RSX-llM logical 
name list for the image. This device information is returned as a 
result of a GET LUN INFORMATION directive. 

The logical names TI , CL, CO, SY, and OV are exceptions to the rules 
for device name mapping. They always map to VAX/VMS logical names, as 
follows: 



RSX-llM Name VAX/VMS Equivalent 



TIO 

CLO 
COO 
SYO 
SPn 

WKn 

LBn 

OVO 



SYS$INPUT 
SYS$OUTPUT 

SYS$ERROR 

SYS $ COMMAND 

SYS$DISK 

Assigned by system 
manager 

Assigned by system 
manager 

Assigned by system 
manager 

For the LUN used by the 
overlay run-time system, 
OVO translates to provide 
access to the task image 
file. 



Name Returned 
for GLUN$ 


$In 
$0n 




$En 




$Cn 




mapped 


name 


mapped 


name 


mapped 


name 


mapped 


name 



Any other LUNs assigned 
to OVO cause VAX/VMS to 
assign the device on 
which the image resides. 



3.7 HANDLING OF QUEUE I/O FUNCTION CODES 

VAX/VMS provides both device-independent and device-dependent 
functions at the Queue I/O Request service level. Device-independent 
functions include read and write virtual block, read and write logical 
block, and read and write physical block. Device-dependent functions 
include operations such as the handling of control and escape 
sequences for terminal I/O and positioning functions for magnetic 
tape, for example, rewind. 
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For most RSX-llM function codes, VAX/VMS has a corresponding function 
code or system service. For example, all disk and most magnetic tape 
function codes have corresponding functions in VAX/VMS. However, two 
areas exist where discrepancies between RSX-llM and VAX/VMS device 
handling may appear; 

• Handling of terminal devices 

• Handling of spooled devices 

Details concerning VAX/VMS handling of all RSX-llM device function 
codes are provided in Chapter 5. The implications of spooling for 
RSX-llM images is described in Section 3.10, "Spooled Devices." 



3 . 8 MAILBOXES 

A mailbox is a record-oriented virtual device used in VAX/VMS for 
generalized communication among processes. VAX/VMS uses a mailbox to 
duplicate the RSX-llM SEND DATA, RECEIVE DATA, and RECEIVE DATA OR 
EXIT directives. These directives are the normal means of intertask 
communication in the RSX-llM environment. 

A mailbox has UlC-based protection associated with it. The creator of 
the mailbox can specify read and write privileges for system, owner, 
group, and world. Because the concepts of execute and delete are not 
meaningful for mailboxes, the creator does not specify privileges for 
these functions. 

When VAX/VMS creates a mailbox for emulating the send/receive 
directives, it specifies read access for the owner and write access 
for the group. The owner is the image issuing the receive directives 
and the group comprises the images issuing the send directives. Owner 
and group are identified by the UIC under which they execute. 



3.8.1 Mailboxes for Send/Receive Directives 

When VAX/VMS loads a compatibility mode image, it determines whether 
the image has a task name by examining the image's task label block. 
The presence of a task name in the label block is an indication that 
the image can issue RECEIVE DATA or RECEIVE DATA OR EXIT directives to 
obtain data sent to it by other images. The system defines a process 
name that is identical to the task name in the label block. If the 
name is unique, just prior to actual image execution, the system 
creates a mailbox and associates it with the process. The mailbox is 
named as follows: 

RCVDtaskname 

rrti J— -nJ^J— -3 U.- ^ « U^ <^1.U^» 4 ^^n i.U-«J- n^w^a J'^4>'v 4-n 

the mailbox must be within the same group and have group or world 
privilege. 

VAX/VMS does not create a mailbox for an image having a task name in 
the form ...xxx, for example, ...MAC. 

Figure 3-3 illustrates the use of mailboxes for the send and receive 
functions. 
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Figure 3-3 Use of Mailboxes for Send/Receive Directives 



3.8.2 I/O to Mailboxes 

A mailbox has a device name of MBAn. The value of n is the unit 
number. VAX/VMS unit numbers are 5-digit numbers in the range to 
65535. When an image creates a mailbox, VAX/VMS assigns a unit number 
to it. Each time an image executes, the unit number assigned by 
VAX/VMS to any mailboxes that the image creates can vary. 

Because mailboxes are treated as devices under VAX/VMS, any RSX-llM 
image can assign a channel to a mailbox using its logical name and 
perform record I/O to it. The RSX-llM image must use the logical name 
rather than the device name (MBAn) to refer to the mailbox because 
RSX-llM images can accept only a unit number in the range to 255. 

Both RSX-llM images and VAX/VMS images can assign a mailbox; however, 
only VAX/VMS images can create a mailbox. Mailboxes assigned by an 
RSX-llM image must be either permanently available in the system or 
created by a native image. Assignment of a mailbox is treated the 
same as the assignment of other VAX/VMS devices for RSX-llM images. 

A mailbox can be shared by native images and RSX-llM images. As a 
result, mailboxes provide a convenient means for native images to 
communicate with RSX-llM images. The mailbox used for such 
communication can be created by a native image or created by VAX/VMS 
for emulating the send and receive directives. 

A native image can send messages to a mailbox created for directive 

emulation by issuing write requests to it. The image can use either 

VAX-11 RMS or the Queue I/O Request system service for the I/O 
'operations. 
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3.9 ACP FUNCTIONS 



RSX-llM Files-11 ACP functions correspond directly to VAX/VMS Files-11 
ACP functions. The mapping is transparent to the RSX-llM image, as 
described in Chapter 5. 



3.10 SPOOLED DEVICES 

Under VAX/VMS, spooling occurs as a result of cooperation among the 
I/O related system services, Files-11 ACP, VAX-11 RMS, and output 
symbionts. Spooling in RSX-llM requires interaction with the RSX-llM 
spooler. Use of VAX/VMS spooled devices is transparent to RSX-llM 
images. 

If an image assigns a device that is spooled (for example, LP) the 
resulting assignment is actually to an intermediate device, for 
example, a disk. If the image issues a GET LUN INFORMATION directive, 
the system returns characteristics that are consistent with the 
intermediate device containing the spooled files. Characteristics of 
the final output device (printer) are not returned to the RSX-llM 
image. 

If an image uses RMS-11 or PCS to access a spooled device, the file is 
spooled when it is deaccessed. 

Use of the QUEUE I/O REQUEST directive to a VAX/VMS spooled device 
without preceding the request with an OPEN$ or appropriate ACP 
functions results in a privilege violation status return. Because the 
device to which the QUEUE I/O DIRECTIVE actually is directed is a 
file-structured device, the appropriate ACP functions (for example, 
access file) must occur before I/O to the device can be performed. 
Use of RMS-11 or FCS PUT$ requests ensures that the ACP functions 
occur. 



3.10.1 ^CS Spooling 

The FCS spooling macro PRINT$ and the services associated with it 
under RSX-llM are supported in VAX/VMS. Spooling in RSX-llM is 
accomplished by a task named PRT... . when VAX/VMS detects a SEND 
DATA directive with PRT... as the target, it executes a Send Message 
to Symbiont Manager system service to spool the file. 
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CHAPTER 4 
DIRECTIVE DESCRIPTIONS 



This chapter is based on Chapter 4 of the RSX-llM Executive Reference 
Manual for RSX-llM Version 3.1. VAX/VMS support of each RSX-llM 
directive is described. Any differences in directive support under 
VAX/VMS are presented in the shaded portions of the individual 
directive descriptions. 

For ease of reference, individual directive descriptions in this 
chapter are in alphabetic order according to the names of the RSX-llM 
directive macro calls. 



4.1 DIRECTIVE CATEGORIES 

This section groups related directives by the following functional 
categories. 

Process control directives 

Informational directives 

Event-associated directives 

Trap-associated directives 

I/O and interprocess communications directives 

The following sections summarize the directives within each category 
in tabular form. One table entry exists for each directive. Each 
table entry lists the differences in RSX-llM and VAX/VMS system 
environments that may affect directive emulation and refers to the 
sections in Chapters 2, 3, and 5 that describe these differences. 



4.1.1 Process Control Directives 

The process control directives deal principally with starting and 
stopping images within a process or in other processes. VAX/VMS 
allows images to affect processes executing in the same group (UIC) as 
the requester. 

Each of these requests (except EXTEND TASK) results in a change of an 
image's state unless the image is already in the state being 
requested. 

Table 4-1 summarizes the process control directives. 
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Table 4-1 
Process Control Directives 



Macro 


Directive Name 


System Differences 


ABRT$ 


ABORT TASK 


Protected by group (Section 2.2). 
Requires privilege (Section 2.1). 
Uses process name (Section 2.4). 


RQST$ 


REQUEST 


Requested image must be in a 
hibernating or active process 
(Section 2.12). Protected by group 
(Section 2.2). Requires privilege 
(Section 2.1). Uses process name 
(Section 2.4) . 


RUN$ 


RUN 


Requested image must be in a 
hibernating or active process 
(Section 2.12). Protected by group 
(Section 2.2). Requires privilege 
(Section 2.1) . Uses process name 
(Section 2.4) . 


SPND$ 


SUSPEND 


Must have process name (Section 
2.4) . 


RSUM$ 


RESUME 


Protected by group (Section 2.2). 
Requires privilege (Section 2.1). 
Uses process name (Section 2.4). 


ALTP$ 


ALTER PRIORITY 


No operation performed (Section 
2.10) . 


DSCP$ 


DISABLE 
CHECKPOINTING 


Requires set swap mode privilege 
(Sections 2.7.1 and 2.1). 


ENCP$ 


ENABLE 
CHECKPOINTING 


Requires set swap mode privilege 
(Sections 2.7.1 and 2.1). 


EXTK$ 


EXTEND TASK 


None. 


CSRQ$ 


CANCEL TIME BASED 
INITIATION REQUESTS 


Protected by group (Section 2.2). 
Requires privilege (Section 2.1) . 
Uses process name (Section 2.4). 


EXIT$S 


TASK EXIT 


Pertains to image termination 
(Section 2.13) . 


EXST$ 


EXIT WITH STATUS 


Pertains to image termination 
(Section 2.13). Used to signal 
error condition to subsequent 
image. 



4.1.2 Informational Directives 

Informational directives provide the issuing image with data retained 
by the system; that is, the time of day, the image run parameters, 
and partition parameters. 

Table 4-2 summarizes the informational directives. 
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Table 4-2 
Informational Directives 



Macro 


Directive Name 


System Differences 


GPRT$ 
GTIM$ 
GTSK$ 


GET PARTITION 
PARAMETERS 

GET TIME PARAMETERS 
GET TASK PARAMETERS 


Returns parameters for GEN 
partition (Section 2.7.1). 

Uses 100 ticks-per-second frequency 
(Section 2.9) . 

Partition name is GEN (Section 
2.7.1) . 



4.1.3 Event-Associated Directives 

The event and event flag directives provide the means for interprocess 
and intraprocess synchronization and signaling. 

Table 4-3 summarizes the event-associated directives. 



Table 4-3 
Event-Associated Directives 



Macro 


Directive Name 


System Differences 


SETF$ 
CLEF$ 
RDAF$ 
WTSE$ 
WTLO$ 


SET EVENT FLAG 

CLEAR EVENT FLAG 

READ ALL EVENT FLAGS 

WAIT FOR SINGLE 
EVENT FLAG 

WAIT FOR LOGICAL 
OR OF EVENT FLAGS 


No differences for local event 
flags. Common event flags are 
protected by group (Section 2.5) 
and require a task name in the 
image label block (Section 2.4) . 

No differences for local event 
flags. Common event flags are 
protected by group (Section 2.5) 
and require a task name in the 
image label block (Section 2.4) . 

No differences for local event 
flags. Common event flags are 
protected by group (Section 2.5) 
and require a task name in the 
image label block (Section 2.4) , 

No differences for local event 
flags. Common event flags are 
protected by group (Section 2.5) 

image label block (Section 2.4). 

No differences for local event 
flags. Common event flags are 
protected by group (Section 2.5) 
and require a task name in the 
image label block (Section 2.4). 



(continued on next page) 
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Table 4-3 (Cont.) 
Event-Associated Directives 



Macro 



DECL$S 

WSIG$S 

MRKT$ 

CMKT$S 

EXIF$ 



Directive Name 



DECLARE SIGNIFICANT 
EVENT 

WAIT FOR SIGNIFICANT 
EVENT 

MARK TIME 



CANCEL MARK TIME 
REQUESTS 

EXIT IF 



System Differences 



Concept does not exist in VAX/VMS 
(Section 2.8) . 

No wait occurs; concept does not 
exist in VAX/VMS (Section 2.8). 

Uses 100 tick-per-second clock 
(Section 2.9) . 

Protected by group (Section 2.2) . 
Requires privilege (Section 2.1). 

No differences for local event 
flags. Common event flags are 
protected by group (Section 2.5) 
and require a task name in the 
image label block (Section 2.4) . 
Pertains to image termination 
(Section 2.13) . 



4.1.4 Trap-Associated Directives 

The trap-associated directives provide the image with the same 

facilities inherent in the PDP-11 hardware trap system. They allow 

transfers of control (software interrupts) to the executing image 
under certain fault conditions. 

Table 4-4 summarizes the trap-associated directives. 



Table 4-4 
Trap-Associated Directives 



Macro 


Directive Name 


System Differences 




SPRA$ 


SPECIFY POWER 
RECOVERY AST 


None. 




SRDA$ 


SPECIFY RECEIVE 
DATA AST 


None. 




SVDB$ 


SPECIFY SST VECTOR 
TABLE FOR DEBUGGING 
AID 


None. 




SVTK$ 


SPECIFY SST VECTOR 
TABLE FOR TASK 


None. 




ASTX$S 


AST SERVICE EXIT 


None. 




DSAR$S 


DISABLE AST 
RECOGNITION 


None. 




ENAR$S 


ENABLE AST 
RECOGNITION 


None. 




SFPA$ 


SPECIFY FLOATING POINT 
PROCESSOR EXCEPTION AST 


None. 
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4.1.5 I/O and Interprocess Communications Directives 

The I/O and interprocess communications directives allow images to 
access I/O devices at the driver interface level, to communicate with 
other processes in the system, and to retrieve the command line that 
initiated the image. 



Table 4-5 summarizes 
directives. 



the I/O and interprocess communications 



Table 4-5 
I/O and Interprocess Communications Directives 



Macro 



ALUN$ 



GLUN$ 

GMCR$ 
QIO$ 

QIOW$ 

SDAT$ 



RCVD$ 



Directive Name 



ASSIGN LUN 



RCVX$ 



GET LUN INFORMATION 

GET MCR COMMAND LINE 
QUEUE I/O REQUEST 



QUEUE I/O REQUEST 
AND WAIT 

SEND DATA 



RECEIVE DATA 



RECEIVE DATA OR 
EXIT 



System Differences 



Subject to VAX/VMS logical name 
translation (Section 3.5). 
Pertains to device assignment 
(Section 3.5) and mapping (Section 
3.6) . 

Returns intermediate device 
characteristics for spooled device 
(Section 3.10) . See also Section 
5.2. 

None, 

See Chapter 5 for differences in 
I/O function codes. 

See to Chapter 5 for differences 
in I/O function codes. 

Uses mailbox (Section 3.8.1) that 
is protected by group (Section 
2.2) . Requires privilege (Section 
2.1) . Uses process name (Section 
2.4) . Also used as special case 
for PRT... (Section 3.10.1). 

Uses mailbox (Section 3.8.1) that 
is protected by group (Section 
2.2). Requires privilege (Section 
2.1) . Uses process name (Section 
2.4) . 

Uses mailbox (Section 3.8.1) that 
is protected by group (Section 
2.2). Requires privilege (Section 
2.1). Requires process name 
(Section 2.4) . 
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4.2 UNSDPPORTED DIRECTIVES 

VAX/VMS does not support the directives listed below. 

ATTACH REGION (ATRG$) 

CONNECT TO INTERRUPT VECTOR (CINT$) 

CREATE ADDRESS WINDOW (CRAW$) 

CREATE REGION (CRRG$) 

DETACH REGION (DTRG$) 

ELIMINATE ADDRESS WINDOW (ELAW$) 

GET MAPPING CONTEXT (GMCX$) 

GET REGION PARAMETERS (GREG$) 

GET SENSE SWITCH {GSSW$) 

MAP ADDRESS WINDOW (MAP$) 

RECEIVE BY REFERENCE (RREF$) 

SEND BY REFERENCE (SREF$) 

SPECIFY RECEIVE-BY-REFERENCE AST (SRRA$) 

UNMAP ADDRESS WINDOW (UMAP$) 

VAX/VMS returns an error status of lE.SDP (invalid directive) to any 
RSX-llM image that issues an unsupported directive. 

Under RSX-llM, the CONNECT TO INTERRUPT VECTOR directive is used by 
user-written I/O drivers. Under VAX/VMS, an RSX-llM image cannot 
receive device interrupts; therefore, VAX/VMS does not support the 
CONNECT TO INTERRUPT VECTOR directive. 

The VAX-11/780 processor does not have sense switches. Therefore, 
VAX/VMS handles the GET SENSE SWITCH directive in the same manner as 
RSX-llM does for a system that disallowed access to sense switches 
during system generation. It returns the DSW status lE.SDP. 

The remaining 12 directives are RSX-llM memory management (PLAS) 
directives. They are not supported because a VAX-11/780 performs 
memory management very differently from the way that a PDP-11 does. 
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4.3 SYSTEM DIRECTIVE DESCRIPTIONS 

Each directive description includes all or most of the following 
elements, as appropriate: 

Name: 

The function of the directive in VAX/VMS is described. 

Macro Call: 

The macro call is shown, each parameter is defined, and the 
defaults for optional parameters are given in parentheses 
following the definition of the parameter. Since zero is 
supplied for most defaulted parameters, only nonzero default 
values are shown. Parameters ignored by VAX/VMS and RSX-llM are 
required for compatibility with RSX-llD and IAS. 

DSW Return Code: 

All return codes that are valid under VAX/VMS are listed and 
defined. In some cases, a VAX/VMS return status code in 
parentheses follows an RSX-llM status code. For example: 

lE.RSU — Device allocated to another image (SS$_DEVALLOC) 

The VAX/VMS code indicates the VAX/VMS error that caused the 
corresponding RSX-llM code to be returned. 

Some RSX-llM codes reflect several VAX/VMS codes. In this case, 
VAX/VMS returns the RSX-llM code that it uses by default. Such 
codes are followed by the phrase "default error" in parentheses. 
For example: 

lE.IDU — Device or unit unknown (default error) 

In some cases after a directive failure, VAX/VMS returns an error 
code that is more meaningful for an I/O operation. In these 
cases, the high-order byte of the DSW contains 0. 



Notes: 



The notes presented with some directive descriptions further 
explain the function, use, and/or consequences of these 
directives under VAX/VMS. Users should read the notes carefully 
to ensure proper use of directives. 
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ABRT$ 

4.3.1 ABORT TASK 

The ABORT TASK directive instructs the system to terminate the 
execution of the indicated process's image. The requester can abort 
itself or an image executing in another process. ABORT TASK is 
intended for use as an emergency or fault exit. 

Macro Call: 

ABRT$ tsk 



DSW Return Codes: 

IS. sue — Successful completion 

IE. INS — Process name unknown (default error) 

lE.PRI — User not privileged (SS$ NOPRIV) 

lE.ADP — Part of the DPB is out of the issuing image's 

address space 
lE.SDP — Die or DPB size is invalid 



Notes; 



• VAX/VMS executes a Force Exit system service to terminate the 
specified process's image on behalf of the image issuing the 
ABORT TASK directive. 

• The image issuing the ABORT TASK directive must be executing 
in a process that meets either of the following requirements: 

It is in the same group as the process to be aborted and 
has group privilege. 

It has world privilege. 

• The exit status is supplied by an exit handling routine (exit 
handler) . It is assumed that the status returns a severe 
error. 
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ALTP$ 



4.3.2 ALTER PRIORITY 

VAX /VMS aoes not emulate the ALTER PRIORITY directive. Instead, it 
allows tne process for which the directive was issued to continue 
execution at its present piiority. 

Macro Call: 

ALTP$ [tsk] [,pri] 

tsk = Active task name 

pri = New priority, a number from 1 to 250 (decimal) 

DSW Return Codes: 

IS. sue — Successful completion 

lE.ADP — Part of the DPB is out of the issuing image's 

address space 
IE. SOP — Die or DPB size is invalid 
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ALUN$ 



4.3.3 ASSIGN LUN 

The ASSIGN LUN directive instructs the system to assign a physical 
device unit to a logical unit number. An I/O channel is the VAX/VMS 
equivalent of an RSX-llM logical unit number. 

Tilt, rca'j^iqnmont of a ijii", tinm "ne ilt.\ ic t) anotht i cii'se- v'AX/VMtJ to 
cancel all 1 O tequ- t<s tor tho proviou'- a^signm-rit. 

Macro Call: 

ALUN$ lun,dev,unt 

lun = Logical unit number 

dev = Device name (two characters) 

unt = Device unit number 

DSW Return Codes: 



IS. sue — Successful completion 

lE.IDU — Device or unit unknown (default error) 

lE.ILU — Invalid logical unit number 

lE.ADP — Part of the DPB is out of the issuing image's 

address space 
lE.SDP — Die or DPB size is invalid 




Notes: 



VAX/VMS executes an Assign I/O Channel system service 
behalf of the image issuing the ASSIGN LUN directive. 



on 



• The assignment of RSX-llM device names 
devices is described in Section 3.5. 



to VAX/VMS physical 



If the RSX-llM device name and 
assigned as the logical name of 
the RSX-llM device name and un 
VAX/VMS device name, controlle 
the mapping, VAX/VMS divides th 
(decimal) . The quotient i 
representing the character A 
controller designation. The 
unit number. The following is 



logical unit number are not 
a VAX/VMS device, VAX/VMS maps 
it number to an appropriate 
r, and unit number. To perform 
e RSX-llM unit number by 16 
s added to the ASCII value 
(65) . The result is the 
remainder becomes the VAX/VMS 
an example of the conversion. 



RSX-llM device name and unit number = DB2 

A +_2 = A+0 with a remainder of 2; that is, device 
16 DBA2. 



Corresponding VAX/VMS device name, controller letter, and unit 
number = DBA2 

If a LUN is reassigned, its previous assignment is deassigned. 
The deassignment causes I/O to be cancelled on the old 
■assignment. If the attempt to make a new assignment fails, 
the LUN remains deassigned. 
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ASTX$ 



4.3.4 AST SERVICE EXIT 



The AST SERVICE EXIT directive instructs the system" to terminate 
execution of an AST service routine. 

If another AST is queued and ASTs are not disabled, VAX/VMS 
immediately effects the next AST. Otherwise, the system restores the 
image's state prior to the AST. 

Macro Call: 

ASTX$S [err] 

err = Error routine address 

DSW Return Codes: 

IS. sue — Successful completion 

IE. AST — Directive not issued from an AST service routine 

lE.ADP — Part of the DPB or stack is out of the issuing 

image's address space 
lE.SDP — Die or DPB size is invalid 



Note: 



• 



When an AST occurs, VAX/VMS pushes, at minimum, the following 
information onto the stack: 

SP+06,012 ~ 

SP+04 — PS of process prior to AST 

SP+02 — PC of process prior to AST 

SP+00 — DSW of process prior to AST 

The stack must be in this state when the AST SERVICE EXIT 
directive is executed. 
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CLEF$ 

4.3.5 CLEAR EVENT FLAG 

The CLEAR EVENT FLAG directive instructs the system to clear an 
indicated event flag and report the flag's polarity before clearing. 

Macro Call: 

CLEF$ efn 

efn = Event flag number 

DSW Return Codes: 

IS.CLR — Successful completion; flag was already clear 

IS. SET — Successful completion; flag was set 

lE.irh — Invalid -iV-nt flaq nami ■ i fout 'if thp r-in"o 1 tn 

64) , or 3 i-om-nnn cent Cla] clu'tet i^ not 

aoso(,iatod and a tlan m thf» rtinjf Jj to 04 h is 

5iJ«-C] f ipd 
lE.ADP — Part of the DPB is out of the issuing image's 

address space 
lE.SDP — Die or DPB size is invalid 



Notes: 



VAX/VMS executes a Clear Event Flag system service on behalf 
of the image issuing the CLEAR EVENT FLAG directive. 

VAX/VMS converts the RSX-llM event flag numbers to VAX/VMS 
event flag numbers. The local RSX-llM event flag numbers 1 
through 32 become VAX/VMS local flag numbers 32 through 63. 
The RSX-llM common event flag numbers 33 through 64 become 
flag numbers 64 through 95 in a VAX/VMS event flag cluster 
named RSXCOMEFN. 

Access to common event flags is protected by group number. 

An image that wants to use common event flags must have been 
built with a task name. The DSW status lE.IEF is returned if 
an image that does not have a common event flag cluster 
associated with it attempts to clear flags 33 through 64. 
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CMKT$S 



4.3.6 CANCEL MARK TIME REQUESTS 

The CANCEL MARK TIME REQUESTS directive instructs the system to cancel 
all mark time requests that were made by the issuing image. 

Macro Call: 

CMKT$S [,,err] 

err = Error routine address 

DSW Return Codes: 

IS. sue — Successful completion 

lE.ADP — Part of the DPB is out of the issuing image's 

address space 
lE.SDP — Die or DPB size is invalid 



Note: 



• VAX/VMS executes a Cancel Timer Request system service 
specifying that all timer requests be canceled for the image 
issuing the CANCEL MARK TIME REQUESTS directive. 
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CSRQ$ 



4.3.7 CANCEL TIME BASED INITIATION REQUESTS 

Thfe CAK(.=.L ilMI BASLD I?IIT1ATI0N REQUESTS dli active instructE the 
syctem t > oirc- 1 :ill time-svni-hronized wakeup requests for a specified 
procfss'o i..i>2ijo ii.yaidleFS of the source of each loqufst. 

Macro Call: 

CSRQ$ tsk 

tsk = VaX/VHS pioctiss name 

DSW Return Codes: 

IS. sue — Successful completion 

lE.INS — Specified process name unknown (default error) 

lE.PRI — Privilege violation (SS$_NOPRIV) 

lE.ADP — Part of the DPB is out of the issuing image's 

address space 
lE.SDP — Die or DPB size is invalid 



Notes; 



VAX/VMS executes a Cancel Wakeup system service on behalf of 
the image issuing the CANCEL TIME BASED INITIATION REQUESTS 
directive. 

The image issuing the CANCEL TIME BASED INITIATION REQUESTS 
directive must be executing in a process that meets either of 
the following requirements: 

It is in the same group as the process for which requests 
are to be canceled and has group privilege. 

It has world privilege. 
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DECL$S 

4.3.8 DECLARE SIGNIFICANT EVENT 

The DECLARE SIGNIFICANT EVENT directive instructs the system to 
declare a significant event. Declaration of a significant event has 
no effect in a VAX/VMS system; bhe concept of a significant event m 
the RSX-IlM sense does not esist in VAX/VMS. 

Macro Call: 

DECL$S [,err] 

err = Error routine address 

DSW Return Codes: 

IS. sue — Successful completion 

lE.ADP — Part of the DPB is out of the issuing image's 

address space 
lE.SDP — Die or DPB size is invalid 

Note; 

• No operation is performed and success is returned. 
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DSAR$S 

or 
IHAR$S 

4.3.9 DISABLE (or INHIBIT) AST RECOGNITION 

The DISABLE AST RECOGNITION directive instructs the system to disable 
recognition of user-level ASTs for the issuing image. The ASTs are 
queued as they occur and are effected when the image enables AST 
recognition. When an AST service routine is executing, AST 
recognition also is disabled. The initial state of an image is to 
have recognition enabled. 

Macro Call: 

DSAR$S [err] 

or 
IHAR$S [err] 

err = Error routine address 



DSW Return Codes: 

IS. sue — 

IE. ITS — 
lE.ADP — 



lE.SDP — 



Successful completion 

AST recognition is already disabled 

Part of the DPB is out of the issuing image's 

address space 

Die or DPB size is invalid 



Note: 



• While disabled, ASTs are queued in a first-in/first-out list. 
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DSCP$S 



4.3.10 DISABLE CHECKPOINTING 

Tne DISABLE CHECKPOINTING directive instructs the system to disable 
snapping for thp process. 



Macro Call: 

DSCP$S [err] 

err = Error routine address 

DSW Return Codes: 

IS.SUC — Successful completion 
IE. ITS — Swapping already disabled 



lE.ADP — Part of the DPB is out of the issuing image's 

address space 
lE.SDP — Die or DPB size is invalid 



Notes: 



• VAX/VMS executes a Set Swap Mode system service on behalf of 
the image issuing the DISABLE CHECKPOINTING directive. 

• The image's initial state has swapping enabled. 

• The requesting image must have the privilege to set its swap 
mode. 
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ENAR$S 



4.3.11 ENABLE AST RECOGNITION 

The ENABLE AST RECOGNITION directive instructs the system to recognize 
user-level ASTs for the issuing image; that is, the directive 
nullifies a DISABLE AST RECOGNITION directive. ASTs that were queued 
while recognition was disabled are effected at issuance. The initial 
state of an image is to have AST recognition enabled. 

Macro Call: 

ENAR$S [err] 

err = Error routine address 

DSW Return Codes: 

IS. sue — Successful completion 

IE. ITS — AST recognition is not disabled 

lE.ADP — Part of the DPS is out of the issuing image's 

address space 
lE.SDP — Die or DPB size is invalid 
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ENCP$S 

4.3.12 ENABLE CHECKPOINTING 

The ENABLE CHLCKPOINTING directive instructs the svstem to enable 
swapping for the process. 

Macro Call: 

ENCP$S [e'rr] 

err = Error routine address 

DSW Return Codes: 

IS. sue — Successful completion 
lE.ITS •-— Swapping already enabled 



lE.ADP ~ Part Of the DPB is out of the" issuing image's 

address space 
lE.SDP — DIG or DPB size is invalid 



Notes: 



• VAX/VMS executes a Set Swap Mode system service on behalf of 
the image issuing the ENABLE CHECKPOINTING directive. 

• The initial state of an image has swapping enabled. 

• The requesting image must have the privilege to set its swap 
mode. 
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EXIF$ 



4.3.13 EXIT IF 

The EXIT IF directive instructs the system to terminate execution of 
the issuing image if the specified event flag is not set. VAX/VMS 
returns control to the issuing image if the specified event flag is 
set. 

Macro Call: 

EXIF$ efn 

efn = Event flag number 

DSW Return Codes: 




address space 
IE. SOP — Die or DPB size is invalid 



Notes; 



VAX/VMS converts the RSX-llM event flag numbers to VAX/VMS 
event flag numbers. The local RSX-llM event flag numbers 1 
through 32 become VAX/VMS local event flag numbers 32 through 
63. The RSX-llM common event flag numbers 33 through 64 
become flag numbers 64 through 95 in a VAX/VMS common event 
flag cluster named RSXCOMEFN. 

Access to common event flags is protected by group number. 

An image that wants to use common event flags must have been 
built with a task name. The DSW status lE.IEF is returned if 
an image that does not have a common event flag cluster 
associated with it attempts to test flags 33 through 64. 
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EXITS 



4.3.14 TASK EXIT 



The TASK EXIT directive instructs the system to terminate execution of 
the issuing image. 

Macro Call; 

EXIT$S [err] 

err = Error routine address 

DSW Return Codes: 

lE.ADP — Part of the DPB is out of the issuing image's 

address space 
IE. SOP — Die or DPB size is invalid 



Notes: 



• A return to the image occurs only if the directive is 
rejected. 

• VAX/VMS executes an Exit system service on behalf of the 
issuing image. The success status is returned. 
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EXST$ 



4.3.15 EXIT WITH STATUS 

The EXIT WITH STATUS directive instructs the system to terminate 
execution of the issuing image and to accept from the image a status 
code indicating whether the termination is normal or abnormal. 

Macro Call: 

EXST$ sts [,err] 

sts = exit status 

EX$SUC — Normal termination (RSX$ EXITSTATUS) 
EX$WAR — Warning (RSX$_EXITSTATUST 
EX$ERR — Abnormal termination (RSX$_EXITSTATUS) 
EX$SEV — Severe error termination {RSX$_EXITSTATUS) 

err = Error routine address 

DSW Return Codes: 

lE.ADP — Part of the DPB is out of the issuing image's 

address space 
IE. SOP — Die or DPB size is invalid 



Notes: 



• A return to the image occurs only if the directive is 
rejected. 

• VAX/VMS executes an Exit system service specifying the exit 
status of the image. 
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EXTK$ 



4.3.16 EXTEND TASK 



The EXTEND TASK directive instructs the system to modify the size of 
the issuing task by a positive or negative increment of 32-word 
blocks. If the directive does not specify an increment value, VAX/VMS 
makes the issuing image's size equal to its initial size. 

Macro Call: 

EXTK$ [inc] 

inc = A positive or negative number equal to the number of 
32-word blocks by which the image size is to be 
extended or reduced 

DSW Return Codes: 

IS. sue — Successful completion 

lE.ALG — The issuing image attempted to reduce its size 
to less than the size of its header; or the 
image tried to increase its size beyond 32K 
words or beyond the base of the lowest mapped 
library or common block 

lE.ADP — Part of the DPB is out of the issuing image's 
address space 

lE.SDP — Die or DPB size is invalid 



Notes: 



An image cannot extend itself past its 65K byte address space 
or, if libraries or common areas are present, past the base of 
the lowest mapped library or common block. 

An image can extend itself to the base of its read-only 
section. 
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GLUN$ 



4.3.17 GET LUN INFORMATION 

The GET LUN INFORMATION directive instructs the system to fill a 
6-word buffer with information about a physical device unit to which a 
LUN is assigned. 

Macro Call: 

GLUN$ lun,buf 

lun = Logical unit number 

buf = Address of 6-word buffer that is to receive the LUN 
information 



Buffer Format: 
WD. 00 
WD. 01 

WD. 02 



Name of assigned device 

Unit number of assigned device in the low-order byte. 

First device characteristics word: 

Bit — Record-oriented device (l=yes) [FD.REC]* 

Bit 1 — Carriage-control device (l=yes) [FD.CCL] 

Bit 2 — Terminal device (l=yes) [FD.TTY] 

Bit 3 — Directory device (l=yes) [FD.DIR] 

Bit 4 — Single directory device {l=yes) [FD.SDI] 

Bit 5 — Sequential device (l=yes) [FD.SQD] 






Bit 14 — Device mountable as a Files-11 device 

(l=yes) 
Bit 15 — Device mountable (l=yes) 



WD. 03, 04 VAX- VMS de/ice-dffondent lonuword . Th>. 
this longword at'. doscrihccJ iii tht^ ^I 
iJuilI;; 




WD. 05 



Standard device buffer size 






DSW Return Codes: 
IS. sue - 

lE.ULN - 
lE.ILU - 
lE.ADP - 



lE.SDP — 



Successful completion 

Unassigned LUN 

Invalid logical unit number 

Part of the DPB or buffer is out of the issuing 

image's address space 

Die or DPB size is invalid 



* Bits with associated symbols have the symbols shown in square 
brackets. These symbols can be defined for use by an image by means 
of the FCSBT$ macro. See the IAS/RSX-11 I/O Operations Reference 
Manual . 
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Notes: 



• VAX/VMS executes a Get Channel Information system service on 
behalf of the image issuing the GET LUN INFORMATION directive. 

• VAX/VMS converts the name and unit number of the VAX/VMS 
device to which the LUN is assigned to an RSX-llM device name 
and unit number before returning the LUN information. 

To convert from a VAX/VMS device name to the RSX-llM form, 
VAX/VMS subtracts the value representing the ASCII character A 
(65) from the value of the ASCII character representing the 
controller letter and multiplies the result by 16 (decimal) .. 
It then adds the VAX/VMS unit number. The final result is an 
RSX-llM unit number that is appended to the 2-character device 
name. For example, the VAX/VMS device name TTA2 converts to 
the RSX-llM device name TT2. 

TTA2 to TT2: 

Unit =((A - A) * 16)+2 = (0 * 16) + 2 = 2 

• If the device to which the LUN is assigned is a spooled device 
(for example, LP) , VAX/VMS returns the characteristics of the 
intermediate device (for example, disk) . 

• Mailboxes have 16-bit unit numbers. The low-order 8 bits are 
returned by GET LUN INFORMATION in word 1. Mailboxes must be 
referred to using a logical name rather than using the unit 
number returned. 
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GMCR$ 



4.3.18 GET MCR COMMAND LINE 

The GET MCR COMMAND LINE directive instructs the system to transfer an 
80-byte command line to the issuing image. It is the command line 
used to invoke the image. As a result, it can be in either MCR or DCL 
format. 

Macro Call: 

GMCR$ 

DSW Return Codes: 

+n — Successful completion; n is the number of data 
bytes transferred, excluding the termination 
character. The termination character is, 
however, in the buffer 

IE. AST — No command line exists for the issuing image; 
that is, the image was not requested by a 
command other than RUN or the image has already 
issued the GET MCR COMMAND LINE directive 

lE.ADP — Part of the DPB is out of the issuing process's 
address space 

lE.SDP — Die or DPB size is invalid 



Notes: 



The system processes all lines to: 

— Convert tabs to a single space 

— Convert multiple spaces to a single space 

— Convert lowercase characters to uppercase 

— Remove all trailing blanks 

The terminator <CR> is the last character in the line. 

The command line can be the result of the following types of 
user-issued DCL commands: 



Format 

$ MCR name command-string 

$ MCR 

MCR> name command-string 



Example 

$ MCR PIP LP:=MYFILE 

$ MCR 

MCR>PIP LP:=MYFILE 
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• The command line can be the result of he following types of 
MCR commands: 

Format Example 

>name command-string >PIP LP:=MYFILE 

>name >PIP 

followed by prompt PIP> 

• The command line received as a result of the GET MCR COMMAND 
LINE directive varies depending on the format of the command 
typed. If the command contains a command string, for example, 
LP:=MYFILE, that String and its length are available to the 
image. If no string is supplied, VAX/VMS returns a command 
string length of zero. 

• When an image executes as a result of a RUN command (either 
DCL or MCR) , the command line is zero-length. 
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GPRT$ 



4.3.19 GET PARTITION PARAMETERS 

The GET PARTITION PARAMETERS directive instructs the system to fill an 




Macro Call: 

GPRT$ [prt] ,buf 

prt = Partition name 

buf = Address of a 3-word buffer 

The buffer has the following format; 

V*D. U ~ 400 fa; WiM 

KD. 1 — iTiaijc siz> , including all libcarif^", txpit^stfeil l^^i 



a nultiple ot 64 bytcr, ggj 

hD. A — A vdlu*» of 13 letumed to indicatt wmsm, 



IP; 



SS*; 



svEtem-controllt-J -jartitinn S^S*?- 

DSW Return Codes: 

Successful completion is indicated by carry clear and $DSW equal to 
indicating a mapped system. 

lE.ADP — Part of the DPB or buffer is out of the issuing 

image's address space 

IE. SOP — Die or DPB size is invalid 
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GTIM$ 



4.3.20 GET TIME PARAMETERS 



The GET TIME PARAMETERS directive instructs the system to fill an 
indicated 8-word buffer with the current time parameters. All time 
parameters are delivered as binary numbers. The value ranges are 
shown in decimal below. 

Macro Call: 

GTIM$ buf 

buf = Address of 8-word buffer 

The buffer has the following format: 

WD. — Year (since 1900) 

WD. 1 — Month (1-12) 

WD. 2 — Day (1-31) 

WD. 3 ~ Hour (0-23) 

WD. 4 — Minute (0-59) 

WD. 5 — Second (0-59) 

DSW Return Codes: 

IS. sue — Successful completion 

lE.ADP — Part of the DPB or buffer is out of the issuing 

image's address space 
lE.SDP — Die or DPB size is invalid 



Notes: 



• VAX/VMS executes a Get Time system service for the image 
issuing the GET TIME PARAMETERS directive. 

• VAX/VMS provides a 100 tick-per-second clock. 
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GTSK$ 



4.3.21 GET TASK PARAMETERS 

The GET TASK PARAMETERS directive instructs the system to fill an 
indicated 16-word buffer with parameters relating to the issuing 
process. 

Macro Call: 

GTSK$ buf 

buf = Address of a 16-word buffer 



The buffer has the following format: 




■fel<:itrix-ji' (tirst half), 
■pjRadix-SO (second half) 
™pn Itadix-jO (GKNl 
'JiiH-JKMLJ X - 5 ( h 1 3 n k r ) 



if an/ 
if any 



WD. 04 — Undefined 

WD. 05^ — Undefined 

WMis"/- Run priority I 

WD. 08 — Number of log 

WD. 09 — Undefined 

WD. 10 — Undefined 

WD. 11 — Address of ta 

WD. 12 — Size of task 

WD. 13 — Size in bytes 
libraries and 



m ISX-1]M task headcL 
wjjf tn** I'lO qroup and numlier codes 



ical I/O units (LUNs) 



sk SST vector tables 
SST vector table in words 
of image's address window 
common areas 

;i=. running; 5 for VAX/VMS 
tilC group and member codc-s 



excluding 



DSW Return Codes: 

IS. sue — Successful completion 

lE.ADP — Part of the DPB or buffer is out of the issuing 

image's address space 
lE.SDP — Die or DPB is invalid 
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MRKT$ 



4.3.22 MARK TIME 



The MARK TIME directive instructs the system to set an event flag 
and/or declare an AST after an indicated time interval. The interval 
begins when the image issues the directive. if an event flag is 
specified, the flag is cleared when the directive is issued and set 
when the interval elapses. If an AST entry point address is 
specified, an AST occurs when the interval elapses. 

Macro Call; 

MRKT$ [efn] ,tmg,tnt[,ast] 

efn = Event flag number 

tmg = Time interval magnitude 

tnt = Time interval unit (1 through 4) 

ast = AST entry point address 



DSW Return Codes: 



IS. sue — Successful completion 
lE.ITI — Invalid time parameter 




lE.UPN — Insufficient dynamic memory (SS$_INSFMEM) 

lE-ADP"*"" — '*Part of the "DP&'^is' oiat of' the' '"issuing" imag'e '*s '*' 

address space 
lE.SDP — Die or DPB size is invalid 



Notes: 



VAX/VMS executes a Set Timer system service on behalf of 
process issuing the MARK TIME directive. 



the 



• If an AST entry point address is specified, the AST service 
routine is entered with the stack in the following state: 



SP+08,14 

SP+06 

SP+04 

SP+02 

SP+00 



- 



PS of process prior to AST 

PC of process prior to AST 

DSW of process prior to AST 

Event flag number or (if none was 

specified in the MARK TIME directive) 



The event flag number must be removed from the stack before an 
AST SERVict; KKlT directive is executed. 
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• VAX/VMS returns the DSW code lE.ITI if the directive specifies 
an invalid time parameter. The time parameter consists of two 
components: the time interval magnitude (tmg) and the time 
interval unit (tnt) . 

A legal magnitude value (tmg) is related to the value assigned 
to the time interval unit (tnt) . The unit values are encoded 
as follows: 

1 = Ticks (1/100 of a second per tick) 

2 = Seconds 

3 = Minutes 

4 = Hours 

The magnitude (tmg) is the number of units to be clocked. The 
following list describes the magnitude values that are valid 
for each type of unit. In no case can the value of tmg exceed 
24 hours. 

If tnt = 0, 1, or 2, tmg can be any positive value with a 
maximum of 15 bits. 

If tnt = 3, tmg can have a maximum value of 1440(10). 

If tnt = 4, tmg can have a maximum value of 24(10). 

• VAX/VMS converts the RSX-llM event flag numbers to VAX/VMS 
event flag numbers. The local RSX-llM event flag numbers 1 
through 32 become VAX/VMS local event flag numbers 32 through 
63. The RSX-llM common event flag numbers 33 through 64 
become flag numbers 64 through 95 in a VAX/VMS event flag 
cluster named RSXCOMEFN. 

• An image that wants to use common event flags must have been 
built with a task name. The DSW status lE.IEF is returned if 
an image that does not have a common event flag cluster 
associated with it attempts to set flags 33 through 64. 

• VAX/VMS enforces a quota on the number of ASTs that a process 
can have pending. 
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QIO$ 



4.3.23 QDEUE I/O REQUEST 

The QUEUE I/O REQUEST directive instructs the system to place an I/O 

request for an indicated physical device unit into a queue of 

priority-ordered requests for that device unit. The physical device 
unit is specified as a logical unit number (LUN) . 

If the directive call specifies an event flag, VAX/VMS clears the flag 
when the request is queued and sets the flag upon request completion. 

The I/O status block is also cleared when the request is queued, and 
set to the final I/O status when the I/O request is complete. If an 
AST service routine entry point address is specified, the AST occurs 
upon I/O completion, and the process's WAITFOR mask word, PS, PC, DSW 
(directive status) , and the address of the I/O status block are pushed 
onto the stack. 

Macro Call: 

QIO$ fnc,lun, [efn] , [pri] , [isb] , [ast] [ ,prl] 

fnc = I/O function code 

lun = Logical unit number 

efn = Event flag number 

pri = Priority; ignored, but must be present 

isb = Address of I/O status block 

ast = Address of AST service routine entry point 

pri = Parameter list of the form <Pl,...,P6> 

DSW Return Codes: 



IS. sue 

lE.ULN 
lE.ILU 
lE.ILF 



IE. NOD — 

lE.UPN — 

lE.ADP — 

lE.SDP — 



Successful completion 

Unassigned LUN 

Invalid LUN 

Invalid event llaq numbci (out n( th»- r 

64), or a common -ve-nt flag clu't 

associittd and a tlaq in the lani*" 33 t 

i:: specified. 

Quota exceeded f.-5SSEXQT'013Li 

Insufficient memory" (SS$_INSFMEM) 

Part of the DPB or I/O status block is out of the 

issuing image's address space 

Die or DPB size is invalid 







Notes: 



• VAX/VMS executes a Queue I/O Request system service on 
of the image issuing the QUEUE I/O REQUEST directive. 



behalf 



Chapter 5 explains function codes, parameter meanings, and I/O 
status block return values. 
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• If the directive call specifies an AST entry point address, 
the process enters the AST service routine with the stack in 
the following state: 

SP+16 - SP+10 - 

SP+06 - PS of process prior to AST 
SP+04 - PC of process prior to AST 
SP+02 - DSW of process prior to AST 

SP+00 - Address of I/O status block, or zero if none 
was specified in the QIO directive. 

The address of the I/O status block, which is a trap-dependent 
parameter, must be removed from the stack before an AST 
SERVICE EXIT directive is executed. 

• VAX/VMS pushes four words of zeros in SP+16 through SP+10. 
RSX-llM pushes three words with undefined contents and a 
1-word event flag mask. 

• If the directive is rejected, the specified event flag is not 
guaranteed to be cleared or set. Consequently, if the process 
indiscriminately executes a WAITFOR directive and the QIO 
directive is rejected, the process may wait forever. Care 
should be taken to ensure that the directive was successfully 
completed. 

• VAX/VMS converts the RSX-llM event flag numbers to VAX/VMS 
event flag numbers. The local RSX-llM event flag numbers 1 
through 32 become VAX/VMS local event flag numbers 32 through 
63. The RSX-llM common event flag numbers 33 through 64 
become flag numbers 64 through 95 in a VAX/VMS event flag 
cluster named RSXCOMEFN. 

• Access to common event flags is protected by group number. 

• An image that wants to use common event flags must have been 
built with a task name. The DSW status lE.IEF is returned if 
an image that does not have a common event flag cluster 
associated with it attempts to set flags 33 through 64. 



• VAX/VMS enforces a quota on the number of ASTs that a 
can have pending. 



process 
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QIOW$ 



4.3.24 QUEUE I/O REQUEST AND WAIT 

The QUEUE I/O REQUEST AND WAIT directive is identical to QUEUE I/O 
REQUEST with one exception: if the wait variation of the directive 
specifies an event flag, VAX/VMS automatically effects a WAIT FOR 
SINGLE EVENT FLAG directive. If an event flag is not specified, 
however, VAX/VMS treats the directive as if it were a QUEUE I/O 
REQUEST. 

Macro Call: 

QIOW$ fnc,lun,efn, [pri] , [isb] , [ast] [ ,prl] 

fnc = I/O function code 

lun = Logical unit number 

efn = Event flag number 

pri = Priority; ignored, but must be present 

isb = Address of I/O status block 

ast = Address of AST service routine entry point 

pri = Parameter list of the form <Pl,...,P6> 

DSW Return Codes: 



IS. sue — Successful completion 

lE.ULN — Unassigned LUN 

lE.ILU — Invalid LUN 
I 




lE.UPN — Insufficient memory (SS$ INSFMEM) 

lE.ADP — Part of the DPB or I/O status block is out of the 

issuing image's address space 
lE.SDP — Die or DPB size is invalid 



Notei 



VAX/VMS executes a Queue I/O Request and Wait for Event Flag 
system service on behalf of the image issuing the QUEUE I/O 
REQUEST AND WAIT directive. 

See the notes for the QUEUE I/O REQUEST directive. 
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RCVD$ 



4.3.25 RECEIVE DATA 

The RECriVE DATA directive instructs the system to leaH a. mo'-=dit fron 
the mailbox created when the image was loaded and place that mes^iqc 
m a butler within the issuing image. 

A 2-word sending process name in Radix-50 form and the 13-word data 
block are returned in a 15-word buffer. 

Macro Call: . 

RCVD$ [tsk] ,buf 

byf, = „A,dd_ress of 15-word buffer 

4lsJc»>t"Sea^ing task ru.n- ; j-mored under VAX/VMS 

DSW Return Codes: 

IS. sue — Successful CQlttpl^tipn 

IF.NUD ~ Quota exceecr0|4^^EXv^ljOTA) 

Ih.lPN ~ In = uffici^nt*infeiro*y^{SS$_INSFHEM) 

IE. ITS — No data currently available in mailbox or no 

mailbox (default error) 
lE.ADP — Part of the DPB or buffer is out of the issuing 

image's address space 
lE.SDP — Die or DPB size is invalid 



Notes! 



• VAX/VMS executes a read Queue I/O Request system service on 
behalf of the process issuing the RECEIVE DATA directive. The 
I/O operation reads data from a mailbox associated with the 
process by VAX/VMS when it loads the image. 

• The name of the mailbox is RCVD followed by the process name, 
that is, RCVDname. 

• The mailbox is not created until the image actually begins to 
execute. 

• Because protection is specified as read access for the owner 
(receiving process) and write access for the group (sending 
processes) , this directive is useful only for passing data 
between processes within the same group. 

• The image issuing the receive directives must have a name 
specified at task build time; that is, the image label block 
must contain a task name. VAX/VMS uses the presence of the 
task name as an indication that the image may wish to receive 
data and sets up the necessary mechanism. 
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RCVX$ 



4.3.26 RECEIVE DATA OR EXIT 



The RECCIVE DATA OR EXIT directive instiucts the system to lead a 
message from the mailbox created when the image was loaded. The 
message was sent to the mailbox previously by another process. If no 
data has been sent, an image exit is effected. 

A 2-word sending process name in Radix-50 form and the 13-word data 
block are returned in a 15-word buffer. 

Macro Call: 

RCVX$ [tsk] ,buf 

buf = Address of 15-word buffer 



DSW Return Codes: 

IS^.S^UC — Successful completion 

lE.ADP — Part of the DPB or buffer is out'of the issuing 

image's address space 
lE.SDP — Die or DPB size is invalid 



Notes: 



• 



VAX/VMS executes a Queue I/O Request system service and, if 
appropriate, an Exit system service on behalf of the process 
issuing the RECEIVE DATA OR EXIT directive. The I/O operation 
reads data from a mailbox associated with the process by 
VAX/VMS when it loaded the image. 

The name of the mailbox is RCVD followed by the process name, 
that is, RCVDname. 

The mailbox is not created until the image actually begins to 
execute. 

• Because protection is specified as read access for the owner 
(receiving process) and write access for the group (sending 
processes) , this directive is useful only for passing data 
between processes within the same group. 

• If no data is obtained from the mailbox, VAX/VMS executes an 
Exit system service for the image. The exit status is 
SS$_NORMAL. 

• The image issuing the receive directives must have a name 
specified at task build time; that is, the image label block 
must contain a task name. VAX/VMS uses the presence of the 
task name as an indication that the image may wish to receive 
data and sets up the necessary mechanism. 

• This directive does not provide the same interlock between the 
sender and the receiver as it does in RSX-llM. 

• If no mailbox exists, the image exits with a success status. 
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4.3.27 READ ALL EVENT FLAGS 

The READ ALL EVENT FLAGS directive instructs the system to read all 64 
event flags for the issuing process and record their polarity in a 
64-bit (4-word) buffer. 

Macro Call: 

RDAF$ buf 

The buffer has the following format: 

WD. 00 — Local flags 1 through 16 

WD. 01 — Local flags 17 through 32 

WD. 02 — Common flags 33 through 48 

WD. 03 — Common flags 49 through 64 

DSW Return Codes: 

IS. sue — Successful completion 

lE.ADP — Part of the DPB or buffer is out of the issuing 

image's address space 
lE.SDP — DIG or DPB size is invalid 



Notes: 




VAX/VMS issues a Read Event Flags system service on behalf of 
the image issuing the READ ALL EVENT FLAGS directive. 

o common event tJaq cluster i.- associated with the 
03£ , tr.e common cvf-nt flags ate returned ^z all zeros. 

VAX/VMS converts the RSX-llM event flag numbers to VAX/VMS 
event flag numbers. The local RSX-llM event flag numbers 1 
through 32 become VAX/VMS local flag numbers 32 through 63. 
The RSX-llM common event flag numbers 33 through 64 become 
flag numbers 64 through 95 in a VAX/VMS event flag cluster 
named RSXCOMEFN. 

Access to common event flags is protected by group number. 

An image that wants to use common event flags must have been 
built with a task name. The DSW status lE.IEF is returned if 
an image that does not have a common event flag cluster 
associated with it attempts to read flags 33 through 64. 
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4.3.28 REQUEST 

l««^^f«*^^ Chapter 2 describes the use of the Hibernate and Wake 
services for real-time images. 

REQUEST is a frequently used subset of the RUN directive. 

Macro Call: 

RQST$ tsk,[prt] ,[pri] [,ugc,umc] 

prt = Partition name; ignored 
pri = Priority; ignored 



system 



DSW Return Codes: 

IS. sue — Successful completion 

IE. INS — Process name not known (default error) 

lE.UPN — Insufficient dynamic memory (SS$ 

lE.ADP — Part Of the DPB is out of the issuing image's 

address space 
lE.SDP — Die or DPB size is invalid 



INSFMEM) 



Notes: 



• VAX/VMS executes a Wake system service on behalf of the 
process issuing the REQUEST directive. 

• The requested process must currently be present in the system; 
that is, either hibernating or active. 

• The image issuing the REQUEST directive must be executing in a 
process that meets either of the following requirements: 

— It is in the same group as the requested process and has 
group privilege. 

It has world privilege. 

• VAX/VMS maintains an indicator to determine whether any wake 
requests have been issued for an active process. If the 
pending wake indicator is set and the process issues a 
hibernaLe ieyuetit, the process remains active, and the pending 
wake indicator is cleared. A subsequent hibernate request 
causes the process to hibernate. 
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4.3.29 RBSOHE 

The RESUME directive instiucts the .-ysttm to awaken dM^^^^^^Sl 
in a state of hibematmn. W§Wfi0Smfmm^i 



Macro Call: 
RSUM$ 



tsk 



mimtm 



DSW Return Codes: 



IS. sue — Successful completion 

IE. INS — Process name unknown (default error) 

lE.PRi _ .": 

lE.ADP — Part of the DPB is out of the issuing image's 

address space 
lE.SDP — Die or DPB size is invalid 



— process name unKnown laej-ctuiu cllui.; 

— Privilege violation (SS$ NOPRIV) 



Notes; 



• VAX/VMS executes a Wake system service on behalf of the 
process issuing the RESUME directive. 

• The image issuing the RESUME directive must be executing in a 
process that meets either of the following requirements: 

— It is in the same group as the process to be resumed and 
has group privilege. 

It has world privilege. 

• VAX/VMS maintains an indicator to determine whether any wake 
requests have been issued for an active process. If the wake 
pending indicator is set and the process issues a hibernate 
request, the process remains active, and the wake pending 
indicator is cleared. A subsequent hibernate (SUSPEND) 
request causes the process to hibernate. 

• If a RESUME directive is issued for an image that is active, 
the status returned is success. The process remains active. 
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4.3.30 RUN 



The RUN directive requests the system to activate a hibernating 
process at a specified future time, and optionally to reactivate that 
process periodically. The schedule time is specified in terms of 
delta time from issuance. If the smg, rmg, and rnt parameters are 
omitted, RUN is the same as REQUEST except that RUN causes the process 
to become active one clock tick after the directive is issued. 

Macro Call: 

RUN$ tsk, [prt] , [pri] , [ugc] , [umc] , [smg] ,snt [ ,rmg,rnt] 



prt = Partition name; ignored 

>ri = Priority; ignored 

smg = Schedule delta magnitude 

snt = Schedule delta unit (either 1, 2, 3, or 4) 

rmg = Reschedule interval magnitude 

rnt = Reschedule interval unit 




DSW Return Codes: 

IS. sue — Successful completion 

IE.INS ^,7-^_Process name unknown 



lEj^ra^ — Insufficient dynamic memory (SS$ INSFMEM) 



lE.ITI — Invalid time parameter 

lE.ADP — Part of the DPB is out of the issuing image's 

address space 
IE. SOP — Die or DPB size is invalid 



Notes: 



VAX/VMS executes a Schedule Wakeup system service on behalf of 
the process issuing the RUN directive. 

The target process must be present in the system. 

The image issuing the RUN directive must be executing in a 
process that meets either of the following requirements: 

It is in the same group as the process to be run and has 
group privilege. 

— It has world privilege. 

VAX/VMS maintains an indicator to determine whether any wake 
requests have been issued for an active process. If the wake 
pending indicator is set and the process issues a hibernate 
request, the process remains active, and the wake pending 
indicator is cleared, A subsequent hibernate (SUSPEND) 
request causes the process to hibernate. 
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Time Intervals 



VAX/VMS returns the DSW code lE.ITI if the directive specifies 
an invalid time parameter. A time parameter consists of two 
components: the time interval magnitude (smg or rmg) and the 
time interval unit (snt or rnt) . 

A legal magnitude value (smg or rmg) is related to the value 
assigned to the time interval unit snt or rnt. The unit 
values are encoded as follows: 

1 = Ticks (1/100 of a second per tick) 

2 = Seconds 

3 = Minutes 

4 = Hours 

The magnitude is the number of units to be clocked. The 
following list describes the magnitude values that are valid 
for each type of unit. In no case can the magnitude exceed 24 
hours. 

If unit = 0,1, or 2, the magnitude can be any positive 
value with a maximum of 15 bits. 

If unit = 3, the magnitude can have a maximum value of 
1440(10) . 

If unit = 4, the magnitude can have a maximum value of 
24(10) . 

The schedule delta time is the difference in time from the 
issuance of the RUN$ directive to the time the process is to 
be run. This time can be specified in the range from one 
clock tick to 24 hours. 
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4.3.31 SEND DATA 



The SEND DATA directive instructs the system to send a 13-word message 
to a nailbox. 

When an event flag is specified in the SEND DATA directive, the 
indicated flag is set for the sending process. 

Macro Call: 

SDAT$ tsk,buf [,efn] 

but *=' Address' of l5-w6rd data buffer 
efn = Event flag number 

DSW Return Codes: 



IS. sue — Successful completion 

IE. INS — Receiver process name unknown (default error) 



lE.tJPN •iC"'*-in'^'{i*f'f|cfent' memory ^(SS$ 'iNSFMEM) 

S2 




image's address space 
lE.SDP — Die or DPB size is invalid 



issuing 



Notes: 



• VAX/VMS executes a write Queue I/O Request system service on 
behalf of the process issuing the SEND DATA directive. The 
I/O operation writes to a mailbox named RCVD followed by the 
specified process name, that is, RCVDname. 

• The sending process must be in the same group as the receiving 
process because protection allows the group write access to 
the mailbox and denies access to the world. 

• The target process must be executing an image that had a name 
specified at task build time; that is, the image label block 
must contain a task name. VAX/VMS uses the presence of the 
task name as an indication that the image is going to receive 
data and sets up the necessary mechanism. 

• An image that wants to use common event flags must have been 
built with a task name. The DSW status lE.IEF is returned if 
an image that does not have a common event flag cluster 
associated with it attempts to set flags 33 through 64. 
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4.3.32 SET EVENT FLAG 

The SET EVENT FLAG directive instructs the system to set an indicated 
event flag and report the flag's polarity before it is set. 

Macro Call: 

SETF$ efn 

efn = Event flag number 

DSW Return Codes: 

IS.CLR — Flag was clear 

IS. SET — Flag was already set 

il^^ST— Invali-#^i/'iiit l la^j numitr (mt in tdnye 1 to 64), 

^^-f^'fi-j'f't; or a e^ion c^,- nt tlai .Jui.t»r il not afasocicti^a 

:'f-ff%^I^f t , an<a ,a ,€la4 in the ranjc J3 throuqh 64 :o 

t^.ADP — Part of the DPB is out of the issuing image's 

address space 
lE.SDP — Die or DPB size is invalid 



Note: 



• VAX/VMS executes a Set Event Flag system service on behalf of 
the image issuing the SET EVENT FLAG directive. 

• VAX/VMS converts the RSX-llM event flag numbers to VAX/VMS 
event flag numbers. The local RSX-llM event flag numbers 1 
through 32 become VAX/VMS local flag numbers 32 through 63. 
The RSX-llM common event flag numbers 33 through 64 become 
flag numbers 64 through 95 in a VAX/VMS event flag cluster 
named RSXCOMEFN. 

• Access to common event flags is protected by group number. 

• An image that wants to use common event flags must have been 
built with a task name. The DSW status lE.IEF is returned if 
an image that is not associated with a common event flag 
cluster attempts to set flags 33 through 64. 
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4.3.33 SPECIFY FLOATING POINT PROCESSOR EXCEPTION AST 

The SPECIFY FLOATING POINT PROCESSOR EXCEPTION AST directive instructs 
the system either to enable or disable delivery of floating point 
processor exception ASTs. 

When an AST service routine entry point address is specified, future 
floating point processor exception ASTs occur for the issuing process, 
and control is transferred to the indicated location at the time of 
the AST's occurrence. When an AST service entry point address is not 
specified, future floating point processor exception ASTs do not occur 
until the image issues a directive that specifies an AST entry point. 

Macro Call: 

SFPA$ [ast] 

ast = AST service routine entry point address 

DSW Return Codes: 

IS. sue — Successful completion 

lE.UPN — Insufficient dynamic memory 

IE. ITS — AST entry point address is already unspecified 

IE. AST — Directive was issued from an AST service routine 

or ASTs are disabled 
lE.ADP — Part of the DPB is out of the issuing task's 

address space 
lE.SDP — DIG or DPB size is invalid 



Notes: 



SPECIFY FLOATING POINT PROCESSOR EXCEPTION AST requires 
dynamic memory. 

VAX/VMS queues floating point processor exception ASTs when a 
floating point processor exception trap occurs for the task. 
No future floating point processor exception ASTs are queued 
for the process until the first one queued has actually been 
effected. 

The floating point processor exception AST service routine is 
entered with the task stack in the following state: 

SP+12 - Event flag mask word 
SP+10 - PS of task prior to AST 
SP+06 - PC of task prior to AST 
SP+04 - DSW of task prior to AST 
SP+02 - Floating exception code 
SP+00 - Floating exception address 

The image must remove the floating exception code and address 
from the stack before an AST SERVICE EXIT directive is 
executed. 

This directive cannot be issued from an AST service routine or 
when ASTs are disabled. 
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SPND$S 



4.3.34 SUSPEND 

The SUSPEND directive instructs the system to place the process in a 
state of hibernation. An image can suspend only the process in which 
it is executing. The suspended process can be restarted by another 
process that issues a RESUME directive for it. 

Macro Call: 

SPND$S [err] 

err = Error routine address 

DSW Return Codes: 

IS.SyC .._--, Successful completion 

lE.ADP — ■' Part of the *DPB Is out of the issuing image's 

address space 
lE.SDP — Die or DPB size is invalid 

Notes: 



VAX/VMS executes a Hibernate system service on behalf 
process issuing the SUSPEND directive. 



of the 



A suspended process retains control of the system resources 
allocated to it. VAX/VMS makes no attempt to free these 
resources. 

VAX/VMS maintains an indicator to determine whether any wake 
requests have been issued for an active process. If the wake 
pending indicator is set and the process issues a hibernate 
request, the process remains active, and the wake pending 
indicator is cleared. A subsequent hibernate request causes 
the process to hibernate. 

If a SUSPEND directive is issued by an image that has pending 
resume requests, the following occurs. 

The status returned is success. 

— The process remains active. 

— The wake pending indicator is cleared. 

A process can be resumed only by specifying its process name; 
therefore, a process is not allowed to suspend itself unless 
it has a process name. 
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SPRA$ 

4.3.35 SPECIFY POWER RECOVERY AST 

The SPECIFY POWER RECOVERY AST directive instructs the system to 
record either of the following: 

• That power-recovery ASTs for the issuing process are desired, 
and the address to which to transfer control when a powerfail 
recovery AST occurs 

• That power-recovery ASTs for the issuing process are no lonqer 
desired 

When an AST service routine entry point address is specified, future 
power recovery ASTs occur for the issuing process. VAX/VMS transfers 
control to the specified address whenever a powerfail recovery occurs. 
When an AST service entry point address is not specified, future power 
recovery ASTs do not occur until an AST entry point is again 
specified . 

Macro Call: 

SPRAS [ast] 

ast = AST service routine entry point address 
DSW Return Codes: 

IS. sue — Successful completion 

IE. ITS ~ AST entry point address is already unspecified 

IE. AST — Directive was issued from an AST service routine 

or ASTs are disabled. 
lE.ADP — Part of the DPB is out of the issuing image's 

address space 
lE.SDP — Die or DPB size is invalid 



Notes; 



• VAX/VMS executes a Set Power Recovery AST system service for 
the image issuing the SPECIFY POWER RECOVERY AST directive. 

• ASTs are disabled while the AST recovery service routine 
executes. They remain disabled until the service routine 
issues an AST SERVICE EXIT directive. 

• The process enters the powerfail AST service routine with the 
task stack in the following state: 

SP+06,12 - 

SP+02 - PC of process prior to AST 
SP+00 - DSW of process prior to AST 

No trap-dependent parameters accompany a power-recovery AST; 
therefore, the AST SERVICE EXIT directive can be executed with 
the stack in the same state as when the AST was effected. 

• This directive cannot be issued from an AST service routine or 
when ASTs are disabled. 
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4.3.36 SPECIFY RECEIVE DATA AST 

The SPECIFY RECEIVE DATA AST directive instructs the system to record 
either of the following conditions: 

• That receive-data ASTs for the issuing image are desired, and 
the address to which to transfer control when data has been 
placed in the image's mailbox (RCVDprocessname) 

• That receive-data ASTs for the issuing task are no longer 
desired 

When the directive specifies an AST service routine entry point 
address, receive-data ASTs for the image occur whenever data has been 
placed in the image's mailbox (RCVDprocessname) . VAX/VMS transfers 
control to the specified address. 

When the directive omits an entry point address, VAX/VMS disables 

receive data ASTs for the issuing image. Receive data ASTs do not 

occur until the image issues another SPECIFY RECEIVE DATA AST 

directive that specifies an entry point address. 

Macro Call: 

SRDA$ [ast] 

ast = AST service routine entry point address 

DSW Return Codes: 

IS. sue — Successful completion 

IE. ITS — AST entry point address is already unspecified 

IE. AST — Directive was issued from an AST service routine 

or ASTs are disabled 
lE.ADP — Part of the DPB is out of the issuing image's 

address space 
lE.SDP — Die or DPB size is invalid 



Notes: 



The task enters the receive-data AST service routine with the 
task stack in the following state: 

SP+06,12 - 

SP+04 - PS of process prior to AST 
SP+02 - PC of process prior to AST 
SP+00 - DSW of process prior to AST 

No trap-dependent parameters accompany a receive-data AST; 
therefore, the AST SERVICE EXIT directive must be executed 
with the stack in the same state as when the AST was effected. 

This directive cannot be issued from an AST service routine or 
when ASTs are disabled. 
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VAX/VMS implements the SPECIFY RECEIVE DATA AST through the 
use of the set AST enable QIO I/O function for an unsolicited 
message to the mailbox. When a message is sent to the 
mailbox, an AST is given to the image. The AST is re-enabled 
by a subsequent AST SERVICE EXIT directive. 

Also refer to Section 4.3.25 for information on the RECEIVE 
DATA directive. 



4-49 



DIRECTIVE DESCRIPTIONS 

SVDB$ 

4.3.37 SPECIFY SST VECTOR TABLE FOR DEBUGGING AID 

The SPECIFY SST VECTOR TABLE FOR DEBUGGING AID directive instructs the 
system to record the address of a table of SST service routine entry 
points for use by an intra- image debugging aid (ODT, for example) . 

To deassign the vector table, the parameters adr and len are omitted 
from the macro call. 

When an SST service routine entry is specified in both the table used 
by the image and the table used by a debugging lid, the trap occurs 
for the debugging aid, not for the image. 

Macro Call: 

SVDB$ [adr] [,len] 

adr = Address of SST vector table 
len = Length of (that is, number of entries in) the table in 
words 

The vector table has the following format; 

WD. 00 — Odd address or nonexistent memory error 

WD. 01 — Memory protection violation 

WD. 02 — T-bit trap or execution of a BPT instruction 

WD. 03 — Execution of an lOT instruction 

WD. 04 — Execution of an illegal or reserved instruction 

WD. 05 — Execution of a non-RSX EMT instruction 

WD. 06 — Execution of a TRAP instruction 

WD. 07 — Not used 

A table entry with a value of indicates that the image does not 
intend to process the corresponding SST. 

DSW Return Codes: 

IS. sue — Successful completion 

lE.ADP — Part of the DPB or table is out of the issuing 

image's address space 
lE.SDP — Die or DPB size is invalid 
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4.3.38 SPECIFY SST VECTOR TABLE FOR TASK 



The SPECIFY SST VECTOR TABLE FOR TASK directive instructs the system 
to record the address of a table of SST service routine entry points 
for use by the issuing image. 



To deassign the vector table, the parameters adr and len 
from the macro call. 



are omitted 



When an SST service routine entry is specified in both the table used 
by the image and the table used by a debugging aid, the trap occurs 
for the debugging aid, not for the image. 

Macro Call: 

SVTK$ [adr] [,len] 

adr = Address of SST vector table 

len = Length of (that is, number of entries in) the table in 
words 

The vector table has the following format: 

WD. 00 — Odd address or nonexistent memory error 

WD. 01 — Memory protection violation 

WD. 02 — T-bit trap or execution of a BPT instruction 

WD. 03 — Execution of an lOT instruction 

WD. 04 — Execution of an illegal or reserved instruction 

WD. 05 — Execution of a non-RSX EMT instruction 

WD. 06 — Execution of a TRAP instruction 

WD. 07 — Not used 

A table entry with a value of indicates that the image does not want 
to process the corresponding SST. 

DSW Return Codes: 

IS. sue — Successful completion 

lE.ADP — Part of the DPB or table is out of the issuing 

image's address space 
lE.SDP — Die or DPB size is invalid 
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WSIG$S 



4.3.39 WAIT FOR SIGNIFICANT EVENT 

Beoauf.'j . i in -I i '".nt ovi.Titfc dc- not cxi^t in VAX, 'VMS, the WAIl FOP 
SIGNIFI' A\ I.v'' M' '^iroctiv, docE. not correcpond to any VAX/VMS cystcm 
service requi :t. tio wait oi-curs when tht- Jiitjctivc is isrued. 



Macro Call: 

WSIG$S [err] 

err = Error routine address 

DSW Return Codes: 

IS. sue — Successful completion 

lE.ADP — Part of the DPB is out of the issuing image's 

address space 
IE. SOP — Die or DPB size is invalid 
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WTLO$ 



4.3.40 WAIT FOR LOGICAL OR OP EVENT FLAGS 



THE WAIT FOR LOGICAL OR OF EVENT FLAGS directive instructs the system 
to @block the execution gf the issuing image uftil VAX/VMS sets an 
indicated event flag from one of the following groups. 

GR — Flags 1 through 16 

GR 1 — Flags 17 through 32 

GR 2 — Flags 33 through 48 

GR 3 — Flags 49 through 64 

The process does not wait if any of the indicated flags is already set 
when it issues the directive. 

Macro Call: 

WTLO$ grp,msk 

grp = Desired group of event flags 
msk = A 16-bit flag mask word 

DSW Return Codes: 



IS. sue 



Successful completion 




lE.ADP — 
lE.SDP — 



Part of the DPB is out of the issuing image's 

address space 

Die or DPB size is invalid 



Notes! 



VAX/VMS executes a Wait for Logical OR of Event Flags system 
service on behalf of the image issuing the WAIT FOR LOGICAL OR 
OF EVENT FLAGS directive. 

VAX/VMS converts the RSX-llM event flag numbers to VAX/VMS 
event flag numbers. The local RSX-llM event flag numbers 1 
through 32 become VAX/VMS local event flag numbers 32 through 
63. The RSX-llM common event flag numbers 33 through 64 
become flag numbers 64 through 95 in a VAX/VMS event flag 
cluster named RSXCOMEFN. 

Access to common event flags is protected by group number. 

Use of common event flags requires the image to have a 
i-oorv-uu^j. ^ iicuiii= . J. u jLo iiuu Quj- J. j.^i.eiiL uu escciuxj-sin a process 
name using the DCL or MCR RUN command. 

The DSW status lE.IEF is returned if an image that does not 
have a common event flag cluster associated with it attempts 
to wait for flags 33 through 64. 



4-53 



DIRECTIVE DESCRIPTIONS 



WTSE$ 



4.3.41 WAIT FOR SINGLE EVENT FLAG 

The WAIT FOR SINGLE EVENT FLAG directive instructs the system to block 
the execution of the issuing image until the indicated event flag is 
set. If the flag is set when the directive is issued, image execution 
continues. 

Macro Call: 

WTSE$ efn 

efn = Event flag number 

DSW Return Codes: 




lE.ADP — Part of the DPB is out of the issuing image's 

address space 
lE.SDP — Die or DPB size is invalid 



Notes: 



• VAX/VMS executes a Wait for Logical OR of Event Flags system 
service for the image issuing the WAIT FOR SINGLE EVENT FLAG 
directive. 

• VAX/VMS converts the RSX-llM event flag numbers to VAX/VMS 
event flag numbers. The local RSX-llM event flag numbers 1 
through 32 become VAX/VMS local event flag numbers 32 through 
63. The RSX-llM common event flag numbers 33 through 64 
become flag numbers 64 through 95 in a VAX/VMS event flag 
cluster named RSXCOMEFN. 

• Access to common event flags is protected by group number. 

• An image that wants to use common event flags must have been 
built with a task name. The DSW status lE.IEF is returned if 
an image that is not associated with a common event flag 
cluster attempts to wait for flags 33 through 64. 
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VAX/VMS images request services directly from I/O drivers and ACPs by 
issuing Queue I/O Request macro instructions. Each macro instruction 
consists of the following types of arguments. 

• An I/O function code 

• Function- independent parameters, for example, I/O channel and 
event flag number 

• Function-dependent parameters PI through P6 
VAX/VMS I/O function code names have the following format. 

IO$_function 

Many function codes have subfunction modifiers that can be associated 
with them. Subfunction modifier names have the following format. 

IO$M_subf unction 

The following are examples of VAX/VMS function codes and subfunction 
modifiers. 

IO$_WRITELBLK 

IO$_READPROMPT!IO$M NOFILTR 
10$ READVBLK 
io$2delete! I0$M_DELETE 

When an RSX-llM image running under VAX/VMS issues a QUEUE I/O REQUEST 
directive, VAX/VMS determines the equivalent native function and 
executes a Queue I/O Request system service on behalf of the image. 
The I/O request is processed by the VAX/VMS I/O system and the 
function is performed by a standard VAX/VMS device driver or ACP. 
Usually, RSX-llM I/O requests correspond to similar VAX/VMS requests. 
As a result, the RSX-llM image is not aware of any differences in the 
I/O systems. However, if an image issues an I/O request that depends 
on idiosyncracies of the RSX-llM I/O system that are not present in 

thp VAX/VMfi T /n cw«34-om t-ha r^^,-,^c-t-^A t /r\ i. -■ t 

exactly as, expected. In that event, the user should consult the 
information in this chapter. 

Each RSX-llM I/O request consists of a function code, 
function- independent parameters, and function-dependent parameters. 
When VAX/VMS receives a QUEUE I/O REQUEST directive, it forms the 
equivalent VAX/VMS arguments for each RSX-llM parameter specified in 
the directive. Because VAX/VMS issues queue I/O requests using the 
VAX/VMS I/O system, it must convert RSX-llM queue I/O requests to the 
native format for processing by the appropriate driver or ACP. 
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VAX/VMS handling of RSX-llM function-independent parameters, for 
example, efn, lun, and ast, is described in Chapters 2 and 3 and 
Section 4.3.23, "QUEUE I/O REQUEST." This chapter' describes how 
VAX/VMS handles I/O function codes and I/O function-dependent 
parameters. 



5.1 SUPPORTED DEVICES 

VAX/VMS supports RSX-llM I/O functions for devices supported by both 
RSX-llM and VAX/VMS; that is, for disks, terminals, line printers, 
card readers, magnetic tapes, and the null device. The VAX/ VMS I/O 
User's Guide lists the devices supported by VAX/VMS. 

If an RSX-llM image performs I/O to a device that VAX/VMS does not 
support and that does not require special-case software, the I/O 
request is handled as if it specified a disk device. The I/O function 
code and parameters (Pi through P6) are handled just as they are for 
disk. No subf unction bits are used. 



5.2 GET LUN INFORMATION DIRECTIVE 

The GET LUN INFORMATION directive returns the same device-independent 
information under VAX/VMS as it does under RSX-llM Version 3.1. The 
format of the information returned for all devices is presented in the 
description of the GET LUN INFORMATION directive (Section 4.3.17). 
The VAX/VMS I/O User's Guide describes the format of the 
device-dependent information returned. 



5.3 STANDARD I/O FUNCTIONS 

The standard RSX-llM I/O functions — attach, detach, and cancel I/O; 
read and write virtual block; and read and write logical block — are 
supported for all devices in VAX/VMS. The sections that follow 
provide additional information about attach, detach, and cancel I/O. 



5.3.1 Attach and Detach I/O Device (10. ATT and lO.DET) 

VAX/VMS categorizes devices as shareable and nonshareable. A 
shareable device, for example, a disk, can be accessed by many users 
without affecting the integrity of the data. Nonshareable devices, 
for example, terminals, allow access from only one process at a time. 
When an image assigns a channel to a nonshareable device, VAX/VMS 
implicitly allocates the device for exclusive use by the process. In 
the RSX-llM sense, it attaches the device for the process. Because 
VAX/VMS performs implicit allocation, images do not have to explicitly 
allocate and deallocate nonshareable devices during execution. 

If an image must have exclusive access to a shareable device, the 
device can be allocated in either of two ways. 

1. By an image issuing an Allocate Device system service 

2. By a user typing an allocate command to a command interpreter 

Use of the allocate command has an advantage over use of the Allocate 
Device system service. It eliminates the need for error recovery by 
the image if the device is not available for allocation. 
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Tasks running in RSX-llM frequently attach terminals and other devices 
to prevent another task from using them. These devices are shareable 
in an RSX-llM system. When an RSX-llM image running under VAXAMS 
issues a QUEUE I/O REQUEST to attach a device, VAX/VMS performs no 
operation and returns a success status to the image. If the target 
device is nonshareable, VAX/VMS allocates the device when the image 
assigns a LUN to it. In effect, therefore, the device is attached. 
If the device is shareable, it remains unallocated after the directive 
status is returned. When an RSX-llM image requires allocation of a 
shareable device, the device must be allocated from a terminal or an 
indirect command file by using an allocate command. 

The RSX-llM function code 10. ATT and lO.DET have meaning for terminals 
under VAX/VMS, as described in Section 5.8, "Terminal Driver." For 
example, issuing an attach or detach causes a cancel CTRL/0 function. 



5.3.2 Cancel I/O Requests (lO.KIL) 

When an RSX-llM image issues a kill I/O request for a VAX/VMS device, 
VAX/VMS executes a Cancel I/O on Channel system service. This system 
service cancels all I/O issued from the designated channel. This 
differs from the RSX-llM approach in that RSX-llM causes all I/O from 
the issuing task to the device to be canceled. When a cancel I/O 
request is issued for a disk device, no operation is performed. 
VAX/VMS returns a success status to the image. 

When the Cancel I/O on Channel system service executes, it notifies 
the driver immediately. Queued I/O requests are canceled immediately; 
however, I/O that the driver is currently processing is not 
necessarily canceled. 



5.4 I/O STATUS BLOCK AND STATUS RETURNS 

When VAX/VMS completes an I/O operation, it returns a code indicating 
the status of the request in an I/O status block. When an RSX-llM 
image issues a request, VAX/VMS returns status information in an I/O 
status block that has the standard RSX-llM format, as illustrated in 
Figure 5-1. 



WordO 



Word 1 



Byte 1 


ByteO 


except for 
terminal read 


Status code 


Number of bytes transferred 



Figure 5-1 Format of RSX-llM I/O Status Block under VAX/VMS 

The return code can be IS.SUC or any of the error status codes listed 
in Table 5-1. The status code IS.SUC corresponds to the VAX/VMS 
status code SS$_NORMAL. VAX/VMS equivalents for RSX-llM error codes 
also are provided in Table 5-1. 
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The high-order byte of word always contains a zero except in the 
case of terminal I/O read requests. For a terminal read request, that 
byte indicates the line terminator, as described in Section 5.8.13, 
"Terminal Read Status Returns." 

The second word of the I/O status block contains the number of bytes 
read or written. 



Table 5-1 
I/O Status Return Codes 



RSX-llM Status 
Return Code 



IE. ABO 
lE.ALN 
IE. BAD 



lE.BDR 
lE.BHD 

lE.BLK 
lE.BVR 
lE.CKS 
lE.CLO 
lE.DAA 

lE.DAO 



lE.DFU 
lE.DNA 
lE.DNR 
lE.DUP 



Equivalent 
VAX/VMS 
Return Code 



SS$_ABORT 
SS$_FILALRACC 
SS$_BADFILENAME 
SS$_BADPARAM 

SS$_BADIRECTORy 

SS$_BADFILEHDR 

SS$_FILESTRUCT 

SS$_ILLBLKNUM 

SS$_BADFILEVER 

SS$_BADCHKSUM 

SS$_FILELOCKED 

SS$_DEVALLOC 

SS$_BUFFEROVF 

SS$_MBTOOSML 

SS$_DATAOVERUN 
SS$_DEVICEFULL 
SS$_DEVNOTALLOC 
SS$_DEVNOTMOUNT 
SS$ DUPPILENAME 



Meaning 



Operation is aborted. 

File already is accessed. 

The file name specified is bad. 

One of the function-dependent 
parameters Pi through P6 is 
invalid on a file operation. 

The directory specified is bad. 

The file header is bad. 

Invalid file structure. 

Illegal block number specified. 

The file version number is bad. 

Bad checksum. 

File is locked. 

Device is allocated to another 
process. 

The block of data being read 
has over&lowed its buffer. 

Message is too big for the 
mailbox. 

Record is too large for buffer. 

The volume is full. 

The device is not allocated. 

The device is not mounted. 

The file name supplied 
duplicates an existing file 
name. 



(continued on next page) 
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Table 5-1 (Cont.) 
I/O Status Return Codes 



RSX-llM Status 
Return Code 



IE. EOF 
IE. EOT 

IE. EXP 
lE.HFU 
lE.IES 

IE. IPC 

lE.LCK 
lE.NLN 
IE. NOD 

lE.NSF 

lE.OFL 
IE. PES 
lE.PRI 

lE.RER 
lE.RSU 



lE.SNC 
lE.SPC 



Equivalent 
VAX/VMS 
Return Code 



SS$_ENDOFFILE 
SS$_ENDOFTAPE 

SS$_FILNOTEXP 

SS$_HEADERFULL 

SS$_BADESCAPE 

SS$_ILLIOFUNC 

SS$_ACCONFLICT 

SSS_FILNOTACC 

SS$_EXQUOTA 

SS$_NOSUCHFILE 

SS$_NOMOREFILES 
SS$_DEVOFFLINE 
SS$_PARTESCAPE 
SS$_NOPRIV 

SS$_FCPREADERR 
SS$ MBFULL 



SS$_FILENUMCHK 
SS$ ACCVIO 



Meaning 



End of file has been reached. 

Physical end of tape has been 
reached. 

File has not expired. 

The file header is full. 

The data being read was 
terminated with an invalid 
escape sequence. 

Function is illegal for the 
device. 

File access conflict. 

File is not accessed. 

The request attempted to exceed 
one of the process's I/O 
quotas, e.g., buffered I/O 
limit. 

The specified file does not 
exist. 

No additional files remain. 

The device is off line. 

Partial escape sequence. 

Process does not have the 
privilege to perform the 
requested function. 

File control primitives 
incurred a read error. 

Mailbox is full. 

AttcuipL Lo enable for CtRL/C 
when another more privileged 
access mode already has enabled 
for it. 

File number check. 

The image attempted to access 
memory that was not in its 
virtual address space. 



(continued on next page) 
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RSX-llM Status 
Return Code 



lE.SQC 
lE.TMO 
KE.WAT 

lE.WER 

lE.WLK 
IS.PND 

IS. sue 



Table 5-1 
I/O Status Ret 



(Cont.) 
urn Codes 



Equivalent 
VAX/VMS 
Return Code 



QS$_FILESEQCHK 

SS$_TIMEOUT 

SS$_BADATTRIB 

SS$_WRITERR 

SS$_WRITLCK 

none 

SS$ NORMAL 



Meaning 



File sequence check failed. 

Device timeout occurred. 

Pile attribute descriptors are 
bad. 

File control primitives 
incurred a write error. 

The device is write locked. 

Request pending. 

Successful operation. 



_L 
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5.5 DISK DRIVER 



Table 5-2 provides the correspondence between RSX-llM disk function 
codes and VAX/VMS disk function codes and resultant actions. 



Table 5-2 
Disk Function Code Correspondence 



Function 



RSX-llM Code 



VAX/VMS Code or Action 



Attach Device 
Detach Device 
Cancel I/O Requests 

Read Logical Block 

Write Logical Block 

Read Virtual Block 

Write Virtual Block 

Read Physical Block 

Write Physical Block 

Write Physical Block 
with deleted data mark 

Load Overlay 



Pack Acknowledge 



10. ATT 
lO.DET 
lO.KIL 

lO.RLB 
lO.WLB 
lO.RVB 
lO.WVB 
lO.RPB 
lO.WPB 
lO.WDD 

lO.LOV 



lO.STC 



No operation in VAX/VMS. 

No operation in VAX/VMS. 

Cancel I/O on Channel 
system service. No 
operation for disks. 

IO$_READLBLK 

IO$_WRITELBLK 

IO$_READVBLK 

IO$_WRITEVBLK 

IO$_READPBLK 

IO$_WRITEPBLK 

Not supported in VAX/VMS. 



Special form of lO.RLB 
performed only on OV: 
(overlay device) . An 
lO.RVB is performed 
on LUNs not assigned 
to OV. 

10$ PACKACK 



Table 5-3 provides the correspondence of RSX-llM function-dependent 
parameters to VAX/VMS arguments. 



Table 5-3 
Disk Parameter Correspondence 



Parameter Function 


RSX-llM Pn 


VAX/VMS Pn 


Starting buffer address 
(staddX 


PI 


PI 


Buffer size (size) 


P2 


P2 


High block number 
(bklh) 


P4 


P3 (high half of longword) 


Low block number (blkl) 


P5 


P3 (low half of longword) 
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5.6 MAGNETIC TAPE DRIVER 



Table 5-4 provides the correspondence between RSX-llM magnetic tape 
function codes and VAX/VMS magnetic tape function codes and resultant 
actions. 



Table 5-4 
Magnetic Tape Function Code Correspondence 



Function 



Attach Device 
Detach Device 
Cancel I/O Requests 

Read Logical Block 

Write Logical Block 

Read Virtual Block 

write Virtual Block 

Write End-of-File Mark 

Read Logical Block 
Reverse 

Rewind Unit 

Rewind and Turn Unit 
Off Line 

Mount Tape and Set 
Characteristics 



Sense Tape Character- 
istics 

Space Blocks 

Space Files 

Set Tape Character- 
istics 



RSX-llM Code 



10. ATT 
lO.DET 
lO.KIL 

10 . RLB 
lO.WLB 
lO.RVB 
lO.WVB 
10. EOF 
lO.RLV 

lO.RWD 
10 . RWU 

lO.SMO 

10. SEC 

lO.SPB 
lO.SPF 
lO.STC 



VAX/VMS Code or Action 



No operation in VAX/VMS. 

No operation in VAX/VMS. 

Cancel I/O on Channel 
system service. 

IO$_READLBLK 

IO$_WRITELBLK 

IO$_READVBLK 

IO$_WRITEVBLK 

IO$_WRITEOF 

IO$_READPBLK! IO$M_REVERSE 

IO$_REWIND 
10$ REWINDOFF 



IO$_SETMODE. Parity and 
density are the charac- 
teristics that can be 
set. 

10$ SENSEMODE 



I0$_SPACERECORD 

IO$_SPACEFILE 

IO$_SETMODE. Parity and 
density are the 
characteristics that can 
be set. 
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Table 5-5 provides the correspondence of RSX-llM function-dependent 
parameters to VAX/VMS arguments. 



Table 5-5 
Magnetic Tape Parameter Correspondence 



Parameter Function 


RSX-llM Pn 


VAX/VMS Pn 


Starting buffer address 
(stadd) 


PI 


PI 


Buffer size (size) 


P2 


P2 


Characteristic bits (cb) 
of lO.SMO and lO.STC 


PI 


PI 


Number of blocks to 


PI 


PI 


space past (nbs) of 
lO.SPB 






Number of EOFs to space 
past (nes) of lO.SPF 


PI 


PI 
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5.7 LINE PRINTER DRIVER 



Table 5-6 provides the correspondence between RSX-llM line printer 
function codes and VAX/VMS function codes or resultant action. 



Table 5-6 
Line Printer Function Code Correspondence 



Function 


RSX-llM Code 


VAX/VMS Code or Action 


Attach Device 


10. ATT 


No operation in VAX/VMS. 
See Section 5.7.1. 


Detach Device 


lO.DET 


No operation in VAX/VMS. 
See Section 5.7.1. 


Cancel I/O Requests 


lO.KIL 


Cancel I/O on Channel system 
service. 


Write Logical Block 


lO.WLB 


IO$_WRITELBLK 


Write Virtual Block 


lO.WVB 


IO$_WRITEVBLK 


Write Physical Block 


lO.WPB 


IO$_WRITEBLK 



Table 5-7 provides the correspondence of RSX-llM function-dependent 
parameters to VAX/VMS arguments. 



Table 5-7 
Line Printer Parameter Correspondence 



Parameter Function 


RSX-llM Pn 


VAX/VMS Pn 




Starting buffer address 


PI 


PI 




(stadd) 








Buffer size (size) 


P2 


P2 




Vertical format control 


P3 


P4 




character (vfc) 









5.7.1 Programming Hints 

• VAX/VMS line printers are not shareable. VAX/VMS implicitly 
allocates a line printer when a channel is assigned. 

• VAX/VMS line printers normally are spooled. A spooled printer 
is allocated to the print symbiont. VAX/VMS does not allow a 
process to allocate a spooled device unless it has the 
privilege to do so. An RSX-llM image is not allowed exclusive 
use of a spooled device (for example, printer) unless the 
process in which it is running has the necessary privilege and 
the allocate command has been issued to reserve the device 
prior to image execution. 
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• If a printer is allocated or not spooled, the RSX-llM image's 
lO.WLB and lO.WVB requests for it produce exactly the same 
results as in the RSX-llM operating system. 

• See Section 3.10, "Spooled Devices," for a discussion of the 
requirements for issuing lO.WLB and lO.WVB requests to a 
spooled device. 

• If an RSX-llM image issues a GET LUN INFORMATION directive for 
a spooled device, the information returned is that for the 
intermediate device. 
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5.8 TERMINAL DRIVER 



Table 5-8 illustrates the correspondence of the RSX-llM 
function-dependent parameters PI through P6 to their VAX/VMS 
equivalents for terminal devices. Table 5-9 provides the 
correspondence of RSX-llM function codes to VAX/VMS functions. Table 
5-10 lists the subf unction bits applicable for each RSX-llM function 
code and provides notes describing VAX/VMS handling of these 
subfunctions for terminals,. 

VAX/VMS places restrictions on the I/O functions that can be performed 
on TI, CO, and CL because they are mapped to process-permanent files. 
It places the same restrictions on I/O to user-created 
process-permanent files. Section 5.8.15, "Programming Hints," 
describes these restrictions. 



Table 5-8 
Terminal Parameter Correspondence 



Parameter Function 


RSX-llM Pn 


VAX/VMS Pn 


Starting buffer address 
(stadd) 


PI 


PI 


Buffer size (size) 


P2 


P2 


Vertical format control 
character (vfc) on write 


P3 


P4* 


Timeout count (tmo) on 
read with prompt 


P3 


P3 


Prompt address (pradd) for 
read with prompt 


P4 


P5 


Prompt size (prsize) for 
read with prompt 


P5 


P6 


Vertical format control 
character (vfc) for read 
with prompt 


P6 


none 



* For all read functions except lO.RPB and lO.RST, the VAX/VMS P4 
parameter specifies RETURN, ESCAPE, and CTRL/Z as terminators. For 
lO.RPB, no characters are terminators. For lO.RST, P4 is 
specifying that all characters with a value less than an ASCII space 
are terminators except form feed, vertical TAB, backspace, delete, 
and TAB. 



5-12 



I/O DRIVERS 



Table 5-9 
Terminal Function Code Correspondence 



Function 


RSX-llM Code 


VAX/VMS Code or Action 


Attach Device 


10. ATT 


Terminal not attached. 
Forces cancel CTRL/0 
on next write. 


Detach Device 


lO.DET 


Terminal not detached. 
Forces cancel CTRL/0 
on next write. 


Cancel I/O Requests 


lO.KIL 


Cancel I/O on Channel 
system service. 


Read Logical Block 


lO.RLB 


IO$_READLBLK 


Write Logical Block 


lO.WLB 


IO$_WRITELBLK 


Read Virtual Block 


lO.RVB 


IO$_READVBLK 


Write Virtual Block 


lO.WVB 


IO$_WRITEVBLK 


Read Physical Block 


lO.RPB 


IO$_READPBLK 


Write Pass All 


lO.WAL 


IO$_WRITEPBLK 


Read Logical Block 
after Prompt 


10 . RPR 


IO$_READPROMPT 


Get Multiple Characteristics 


SF.GMC 


Get I/O Channel Device 
Information system 
service. 


Set Multiple Characteristics 


SF.SMC 


IO$_SETMODE 


Get Terminal Support 


10. GTS 


Standard data returned. 



NOTE 

The remaining device-specific function 
codes are the equivalent of the logical 
OR of a subfunction bit and one of the 
standard function codes 10. ATT, lO.RLB, 
or lO.WLB. See Table 5-10, "Subfunction 
Bit Correspondence." 
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Table 5-10 
Subfunction Bit Correspondence 



FUNCTION 


EQUIVALENT WITH 
SUBFUNCTION BIT 


applicable subfunction bits 

X = Corresponds directly to VAX/VMS function, 
n = Indicates correspondingly-numbered note. 


TF.AST 


tf.bin 


tf.cco 


tf.esq 


tf.ral 


TF.RNE 


tf.rst 


TF.WAL 


tf.wbt 


TF.XOP 


STANDARD 
10. ATT 


FUNCTIONS : 


1 






2 














lO.DET 
























lO.KIL 
























10. RLE 












3 


X 


X 








lO.RVB 












4 


4 


4 








lO.RPB 














X 










lO.WLB 








X 










X 


2 




lO.WVB 








X 










4 


4 




lO.WPB 
























DEVICE-SP 
10. ATA 


ecific functions: 
io.att:tf.ast 

(see Note 1) 








2 














10. ceo 


lO.WLBlTF.CCO 
















X 


2 




SF.GMC 
























10. GTS 
























lO.RAL 


io.rlb!tf.ral 
(see Note 3) 












X 


X 








lO.RNE 


lO.RLBlTF.RNE 










3 




X 








10. RPR 






2 






3 


X 


X 






2 


lO.RST 


IO.RLBITF.RST 










3 


X 










SF.SMC 
























lO.WAL 


lO.WLBlTF.WAL 






X 












2 




lO.WBT 


io.wlb:tf.wbt 

(See Note 2) 






X 










X 




1 



NOTES : 



1. 
2. 



No attach performed. Enables for CTRL/C ASTs only. See Section 5.8.1. 
Subfunction bit ignored for one of the following reasons. 

Function Reason 

TF.ESQ, TF.XON 



TF.WBT 



TF.BIN 



These are characteristics of the terminal line and cannot be 
controlled on a per-request basis. 

The write breakthrough function is not supported in VAX/VMS. 
See Section 5.8.8. 



Function is not supported in VAX/VMS. 
Sets the VAX/VMS function modifier IOSM_NOFILTR. See Section 5.8.4.1. 
RSX-llM virtual functions do not accept these siibf unction bits. 
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5.8.1 10. ATT Function 



When an RSX-llM image issues an 10. ATT for a terminal, VAX/VMS 
performs no operation to alter the attached/detached status of the 
terminal, as described in Section 5.3.1, "Attach and Detach I/O 
Device." VAX/VMS does, however, issue a request to the terminal driver 
to cancel CTRL/0 on the next operation to the terminal if that 
operation is a write. The VAX/VMS terminal driver subfunction 
modifier to cancel CTRL/0 is IO$M_CANCTRLO. The RSX-llM terminal 
driver also forces a cancel CTRL/0 (TP.CCO) on a write operation that 
follows an attach. 

An 10. ATT function issued for TI, CO, or CL becomes a no-op. 



5.8.1.1 lO.ATTITF.AST and 10. ATA Functions - In VAX/VMS, an image can 
enable to receive an AST when a user presses CTRL/C at a terminal. 
When the AST occurs, the image can respond to the CTRL/C. 

The RSX-llM function codes lO.ATTlTF.AST and 10. ATA are equivalent. 
When an RSX-llM image executing in VAX/VMS issues either of these 
codes, VAX/VMS issues a request to the terminal driver to enable the 
image ' for a CTRL/C AST. This function differs from the RSX-llM 
operation in two respects: 

• RSX-llM enables for an AST if any unsolicited character is 
typed. VAX/VMS enables only for a CTRL/C AST. 

• VAX/VMS retains unsolicited input characters other than CTRL/C 
in a typeahead buffer. Under RSX-llM, characters are lost if 
no read is outstanding. For more information, see the 
Terminal Driver chapter of the VAX/VMS I/O User's Guide. 



5.8.1.2 lO.ATTlTP.ESQ Function - In VAX/VMS, certain features that 
are characteristic of a terminal line are set by issuing a set 
terminal mode request (IO$_SETMODE) to the driver. Terminal 
characteristics cannot be altered for the duration of an I/O request 
by specifying a modifier to the request; nor can they be modified as 
a function of terminal allocation. The ability to recognize escape 
sequences on a terminal line is a characteristic of the terminal and 
must be set using IO$_SETMODE or a set command. 

In RSX-llM, the subfunction bit TF.ESQ is used with either of the 
attach function codes (10. ATT or 10. ATA) to indicate that the image 
recognizes any escape sequences generated at the designated terminal. 
When VAX/VMS receives an I/O request containing the TF.ESQ subfunction 
from an RSX-llM image, it ignores that subfunction bit. The terminal 
characteristics remain unaltered. 
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multiple characteristics request (SF.SMC) . 



5.8.2 lO.DET Function 

When an RSX-llM image issues an lO.DET for a terminal, VAX/VMS 
performs no operation to alter the attached/detached status of the 
terminal, as described in Section 5.3.1, "Attach and Detach I/O 
Device." VAX/VMS does, however, issue a request to the terminal driver 
to cancel CTRL/0 on the next operation to the terminal if that 
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operation is a write. The VAX/VMS terminal driver subfunction 
modifier to cancel CTRL/0 is IO$M_CANCTRLO. The RSX-llM terminal 
driver also forces a cancel CTRL/0 (TF.CCO) on a write operation that 
follows a detach. 

An lO.DET function issued for TI, CO, or CL becomes a no-op. 



5.8.3 lO.KIL Function 

An lO.KIL function issued for TI, CO, or CL becomes a no-op. 

5.8.4 lO.RLB, lO.RAL, lO.RNE, and lO.RST Functions 

The function codes lO.RLB, lO.RAL, lO.RNE, and lO.RST all allow an 
image to read a logical block from a terminal. When VAX/VMS receives 
a read logical block request from an RSX-llM image, it issues an 
10$ READLBLK request on behalf of the image. There is a direct 
correspondence between lO.RLB and I0$_READLBLK. The RSX-llM function 
codes lO.RAL, lO.RNE, and lO.RST are the equivalents of the logical OR 
of lO.RLB and a subfunction bit. The following sections describe 
VAX/VMS handling of subfunction bits used with read logical block 
requests. 



5.8.4.1 IG.RLBITF.RAL and lO.RAL - In VAX/VMS, the default terminal 
driver operation on a read request is to intercept and interpret 
control characters, for example, TAB, CTRL/R, CTRL/U, and DELETE. 
However, a native image has two options for restricting the 
interception of control characters by the driver. 

• It can specify the subfunction modifier IO$M_NOFILTR on a read 
function (either I0$_READLBLK, IO$_READVBLK, or 
10$ READPROMPT) to prevent the driver from intercepting 
CTRL/U, CTRL/R, or DELETE. 

• It can issue a read physical block (IO$_READPBLK) request to 
prevent the driver from interpreting any characters. 

Normally, an RSX-llM image that issues a read passing all data request 
actually wants to receive only a subset of the possible control 
characters; that is, it wants to receive CTRL/U, CTRL/R, and DELETE. 
As a result, when VAX/VMS receives an 10 . RLB ! TF . RAL or lO.RAL request 
from an RSX-llM image, it issues a request specifying 
IO$_READLBLK!IO$M_NOFILTR on behalf of the image. 

The VAX/VMS equivalent of the RSX-llM read passing all data function 
is read physical block (IO$_READPBLK) . IO$_READPBLK corresponds 
directly to the RSX-llM function code lO.RPB. lO.RPB has been added 
to the legal set of function codes that can be issued by an RSX-llM 
image to allow execution of the read passing all data function under 
VAX/VMS. An RSX-llM image that wants to perform a read passing all 
data function under VAX/VMS must be modified to issue an lO.RPB. An 
image issuing lO.RPB under the RSX-llM operating system runs without 
receiving an error; that is, lO.RPB is a legal function. 
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NOTE 



In RSX-llM, an lO.RPB request is 
equivalent to an lO.RLB request with a 
subfunction bit set. lO.RAL or lO.RPB 
work on both VAX/VMS and RSX-llM 
systems. 

VAX/VMS requires the image to have the appropriate privilege to read a 
physical block. 



5.8.4.2 lO.RLBITF.RNE and lO.RNE Functions - The RSX-llM function 
codes lO.RLBITF.RNE and lO.RNE are equivalent. Either one corresponds 
directly to the VAX/VMS function code IO$_READLBLK or 10$ READVBLK 
with a no echo function modifier (I0$M NOECHO) . ~ 



5.8.4.3 lO.RLBlTF.RST and lO.RST Functions - The RSX-llM function 
codes 10 . RLB I TF . RST and lO.RST are equivalent. Either one corresponds 
directly to the VAX/VMS function code I0$_READLBLK with a function 
modifier of I0$M_TRMN0ECH0 and a record termination parameter (P4) of 
0. I0$M_TRMN0ECH0 prevents echoing of the line terminator. A record 
termination parameter of causes all characters with a value less 
than an ASCII space to be terminators except form feed, vertical TAB, 
backspace, and TAB, 



5.8.5 10. RPR Function 

The 10. RPR function code corresponds directly to the VAX/VMS 
I0$_READPR0MPT function code. However, the RSX-llM P6 parameter 
(vertical control character) is ignored. VAX/VMS handling of the 
subfunction bits TF.RAL, TF.RNE, and TF.RST with 10. RPR is exactly the 
same as it is for 10. RLB. VAX/VMS does not support use of the 
subfunction bit TF.BIN. VAX/VMS also ignores the subfunction bit 
TF.XOF if it is specified. 

If an 10. RPR function is issued for TI, CO, or CL and these devices 
correspond to process permanent files, the prompt is ignored. 



5.8.5.1 lO.RPRlTF.XGF Function - In VAX/VMS, certain features that 
are characteristic of a terminal line are set by issuing a set 
terminal mode request (IO$_SETMODE) to the driver. A subfunction 
modifier indicates the characteristic to be changed. Terminal 
characteristics cannot be altered for the duration of an I/O request 
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a function of terminal allocation. The ability to control XON/XOFF on 
a terminal line is a characteristic of the terminal and must be set 
using IO$_SETMODE. 

In RSX-llM, the subfunction bit TF.XOF is used with 10. RPR to control 
XON/XOFF at the designated terminal. When VAX/VMS receives an I/O 
request containing the TF.XOF subfunction from an RSX-llM image, it 
ignores that subfunction bit. The terminal characteristics remain 
unaltered . 

To control XON/XOFF, an RSX-llM image should issue a set multiple 
characteristics request (SF.SMC) . 
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5.8.6 lO.RVB Function 



The lO.RVB function code corresponds directly to the VAX/VMS 
IO$_READVBLK. No subfunction bits are supported in RSX-llM for 
lO.RVB. 



5.8.7 lO.RPB Function 

See the discussion of lO.RAL in Section 5.8.4.1. 

5.8.8 lO.WLB, 10. ceo, and 10. WET Functions 

The function codes lO.WLB, lO.CCO, and lO.WBT all allow an image to 
write a logical block to a terminal. When VAX/VMS receives a write 
logical block request from an RSX-llM image, it issues an 
10$ WRITELBLK request. There is a direct correspondence between 
lO.WLB and IO$_WRITELBLK. The RSX-llM function codes lO.CCO, and 
lO.WBT are the equivalents of the logical OR of lO.WLB and a 
subfunction bit. The sections that follow describe VAX/VMS handling 
of subfunction bits on write logical block requests. 



5.8.8.1 lO.WLBlTF.CCO and lO.CCO Functions - The RSX-llM function 
codes lO.WLBlTF.CCO and lO.CCO are equivalent. Either one corresponds 
directly to the VAX/VMS IO$_WRITELBLK function with a function 
modifier of IO$M CANCTRLO. 



5.8.8.2 lO.WLBlWBT and 10. WET Functions - In VAX/VMS, the write break 
through function is implemented using the Broadcast system service. 
As a result, neither of the RSX-llM function codes lO.WLBlWBT or 
10. WET corresponds directly to a VAX/VMS driver function. When an 
RSX-llM image requests write break through, VAX/VMS issues a 
10$ WRITELBLK function to the driver. A normal write logical block 
function occurs. 



5.8.9 lO.WVB Function 

The RSX-llM function code lO.WVB corresponds directly to the VAX/VMS 
function code IO$_WRITEVBLK. VAX/VMS handles the subfunction bits 
allowed with lO.WVB in the same manner as it handles the subfunction 
bits for lO.WLB. The resulting I/O operation is a write virtual 
block, however. 



5.8.9.1 lO.WLBlTF.WAL, lO.WAL, and lO.CCOITF.WAL Functions - The 

RSX-llM function codes lO.WLBlTF.WAL and lO.WAL are equivalent. The 

RSX-llM function lO.CCOITF.WAL adds the cancel CTRL/0 subfunction to 
an lO.WAL request. When an RSX-llM image issues a write all data 

request, VAX/VMS issues an I0$_WRITELBLK1 IO$M_NOFORMAT request to 

cause the data block to be transferred without interpretation to the 
specified buffer. 

VAX/VMS requires an image to have the appropriate privilege to write a 
physical block. An RSX-llM image must have this privilege to 
successfully issue an lO.WAL request. 
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5.8.10 lO.WPB Function 



The RSX-llM function code lO.WPB corresponds directly to the VAX/VMS 
function code IO$_WRITEPBLK. No subf unction bits are applicable. 



5.8.11 10. GTS Function 



VAX/VMS has no system generation options 
included in the terminal driver. 



that control the features 



When an RSX-llM image issues an 10. GTS request, VAX/VMS returns a 
4-word buffer of information that describes the VAX/VMS terminal 
driver features. Because these features cannot be altered, the same 
information always is returned. Table 5-11 lists the terminal support 
information returned under VAX/VMS. 

That information includes all of the features that can be returned 
under RSX-llM with the following exceptions, which are always zero: 



Word 0, 



bit 1 
bit 2 
bit 14 



Fl.BTW 
Fl.BUF 
Fl.UTP 



bit 15 Fl.VBF 



Break through write 

Checkpointing during terminal input 

Input characters buffered in task's 

address space 

Variable-length terminal buffers 



Table 5-11 
Information Returned by Get Terminal Support (10. GTS) 



Bit 



Word 


3 

4 
5 

6 

7 

8 

9 
10 
11 
12 
13 



Word 1 


1 



Words 2 
and 3 



Mnemonic 



Fl.ACR 
Fl.UIA 
Fl.CCO 
Fl.ESQ 

Fl.HLD 
Fl.LWC 
Fl.RNE 
Fl.RPR 
Fl.RST 
Fl . RUB 
Fl.SYN 
Fl.TRW 



F2.SCH 
F2.GCH 



Meaning When Set 



Automatic CR/LF on long lines 

Unsolicited-input-character AST 

Cancel CTRL/0 before writing 

Recognize escape sequences in solicited 

input 

Hold screen mode 

Lower-to-uppercase conversion 

Read with no echo 

Read after prompting 

Read with special terminators 

CRT rubout 

CTRL/R terminal synchronization 

Read all and write all 



Set characteristics QIO (SF.SMC) 
Get characteristics QIO (SF.GMC) 



Undefined in RSX-llM 



An 10. GTS function issued for TI, CO, or CL returns no information. 
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5.8.12 SF.GMC Function 



When an RSX-llM image issues an SF.GMC request, VAX/VMS executes a Get 
I/O Channel Device Information system service and returns the 
appropriate information to the RSX-llM image in the standard format. 
Table 5-12 lists the terminal characteristics that can be returned for 
SF.GMC requests. The RSX-llM characteristic TC.PRI is never returned 
by VAX/VMS because VAX/VMS does not incorporate the concept of a 
privileged terminal. 

Table 5-12 
Terminal Characteristics for SF.GMC and SF.SMC Requests 



RSX-llM Bit 
Name 



TC.ESQ 

TC.HLD 
TC.NEC 
TC.SCP 
TC . SLV 
TC.SMR 
TC . TTP 



Meaning if Set 



Terminal can generate escape 
sequences 

Terminal is in hold screen mode 

Terminal is in no echo mode 

Terminal is a scope 

Terminal is slave 

Uppercase conversion is disabled 

Terminal type 



Corresponding VAX/VMS 
Name 



TM$M_ESCAPE 

TM$M_HOLDSCREEN 

TM$M_NOECHO 

TM$M_SCOPE 

TM$M_NOTYPAHEAD 

TM$M_LOWER 

None 



For the characteristic TC.TTP (terminal type), VAX/VMS always returns 
the value T.UNKO (octal 16) indicating that the terminal type is not 
known . 

An SF.GMC function issued for TI , CO, or CL when the device 
corresponds to a process permanent file becomes a no-op. 



5.8.13 SF.SMC Function 

When an RSX-llM image issues an SF.SMC function, VAX/VMS issues an 
10$ SETMODE request. Table 5-12 provides the correspondence among 
RSX-llM terminal characteristics bit names and VAX/VMS subf unction 
modifiers used with the function code IO$_SETMODE. An RSX-llM image 
cannot set terminal type (TC.TTP) using a SF.SMC function. A DCL or 
MCR SET command can be used to set the terminal type. 

An SF.SMC function issued for TI, CO, or CL when the device 
corresponds to a process permanent file becomes a no-op. 



5.8.14 Terminal Read Status Returns 

The content of an I/O status block used for terminal requests is the 
same as that used for all QIO operations except for terminal read 
operations. For terminal read operations, the high-order byte of the 
first word contains a code that indicates the character or sequence 
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that terminated the read operation. Any one of the following codes 
can be returned. 

• IS.CR Read terminated by RETURN 

• IS. ESC Read terminated by ALTMODE 

• IS. ESQ Read terminated by an escape sequence 

• — Other terminator character 

• Read terminated by full buffer 

5.8.15 Programming Hints 

• VAX/VMS terminals can be spooled. 

• See Section 3.10, "Spooled Devices," for a discussion of the 
requirements for issuing lO.WLB and lO.WVB requests to a 
spooled device. 

• If an RSX-llM image issues a GET LUN INFORMATION directive for 
a spooled device, the information returned is for the 
intermediate device, that is, for a disk. 

• TI, CO, and CL map to VAX/VMS process-permanent files as 
follows: 

RSX-llM Pseudo-Device VAX/VMS Process-Permanent Files 

TI SYS $ INPUT and SYS$OUTPUT 

CO SYS$COMMAND 

CL SYS$ERROR 

• Process-permanent files are controlled using VAX-11 RMS unless 
they map to terminals. VAX/VMS, therefore, limits the I/O 
function codes that can be used to access these files to read 
and write functions only. All subf unction bits are ignored. 
Functions other than read and write are illegal and result in 
the I/O status code lE.IFC (illegal function for this device) 
being returned. 

• For RSX-llM images, user-created process-permanent files 
appear as record-oriented terminal devices. 

• When process-permanent files map to terminals, queue I/O 
requests can be issued. 

• The device characteristics for TI, CO, and CL are as follows: 



hAAl J. ^ 



— terminal 

— 132-byte buffer 

— carriage control 

— no lowercase 



5-21 



I/O DRIVERS 



5.9 CARD READER DRIVER 



Table 5-13 provides the correspondence between RSX-llM card reader 
functions and VAX/VMS function codes or resultant actions. 



Table 5-13 
Card Reader Function Code Correspondence 



Function 


RSX-llM Code 


VAX/VMS Code or Action 


Attach Device 


10. ATT 


No operation 


Detach Device 


lO.DET 


No operation 


Cancel I/O Request 


lO.KIL 


Cancel I/O on Channel system 
service 


Read Virtual Block 


10 . RVB 


IO$_READVBLK 


Read Logical Block 


10 . RLB 


IO$_READLBLK 


Read Logical Block 


10. RED 


IO$_READLBLK ! IO$M_BINARY 



The two function-dependent parameters (Pi and P2) for RSX-llM card 
reader functions correspond directly to Pi and P2 of VAX/VMS card 
reader functions. 
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5.10 NULL DEVICE 



VAX/VMS supports the use of a null device by RSX-llM images. As under 
RSX-llM, a read request to the null device results in an end-of-file 
status return (IE. EOF) , and a write request results in success status 
return (lE.SUC) . 

I/O to the null device is treated like I/O to an unsupported device as 
described in Section 5.1, "Supported Devices." 
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5.11 DISK AND MAGNETIC TAPE ACPS 

I/O operations involving file-structured devices (disk and magnetic 
tape) often require ACP intervention. Normally, RSX-llM images 
perform I/O using RMS-11 or FCS; they do not issue QUEUE I/O REQUEST 
directives directly to an ACP. Any ACP intervention needed is 
requested by RMS-11 or FCS and occurs transparently from the image's 
point of view. It is possible, however, for images to request ACP 
functions directly by issuing a QUEUE I/O REQUEST directive and 
specifying an ACP function code. 

The information in this section is relevant only to RSX-llM images 
that issue ACP functions directly, for example, create file and enter 
file name. Other RSX-llM images running under VAX/VMS can rely on 
RMS-11 or FCS to request appropriate RSX-llM ACP functions during 
image execution. 

VAX/VMS ACP functions are expressed using six function codes and three 
function modifiers. The six function codes follow. 

• IO?_CREATE — Create file 

• IO$_ACCESS — Access file 

• IO$_DEACCESS — Deaccess file 

• IO$_MODIFY — Modify file 

• IO$_DELETE ~ Delete file 

• IO$_ACPCONTROL — ACP control 

The three function modifiers, which can be applied to the create, 
access, and delete functions, follow. 

• IO$M_ACCESS — Open file on user's channel 

• IO$M_CREATE — Create a file identification 

• IO$M_DELETE — Delete file 

By using a function code and a function modifier together, an image 
can request multiple ACP operations in one I/O request. For example, 
IO$_CREATE! IO$M_ACCESS requests the ACP to create a file and to access 
the file on the specified channel. 10$ DELETE! IO$M_DELETE causes a 
file's directory entry and file header to Ee deleted; ~ that is, the 
file is deleted. IO$_DELETE with no function modifier causes the 
file's directory entry to be deleted. 

In addition to function codes and modifiers, VAX/VMS ACPs use a file 
identification block (FIB) as the main means of communication between 
the requester and the ACP. The function-dependent parameter Pi for 
all ACP requests is the address of a descriptor for the associated 
FIB. The FIB contains much of the information passed to an ACP by an 
RSX-llM image in Pi through P6. Figure 5-2 illustrates a FIB. The 
VAX/VMS I/O User's Guide provides a detailed description of the 
contents of a FIB and describes the ACP functions supported by 
VAX/VMS . 
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16 15 



8 7 



I 



FIB$L_ACCTL 
I 



I 
FIB$W_FID 



I 



FIB$W_DID 



I 



FIB$L_WCC 
I 



FIB$W_EXCTL 



FIB$W_NMCTL 



I 



FIB$L_EXSZ 



I 



FIB$L_EXVBN 



FIB$B_ALALIGN 



FIB$B_ALOPTS 



I 
I 
FIB$W_ ALLOC 
I 
I 
I 



RSX-llM 
codes: 



Figure 5-2 File Identification Block Format 



ACP functions are expressed using the following function 



• lO.CRE ~ Create file 

• lO.ACR — Access for read 

• lO.ACW — Access for write 

• 10. ACE — Access for extend 

• 10. EXT — Extend file 

• 10. WAT — Write attributes 

• 10. RAT — Read attributes 

• lO.DAC — Deaccess file 

• 10. DEL — Delete file 

• lO.PNA — Find file name 

• lO.RNA — Remove file name 

• lO.ENA — Enter file name 

• lO.APC ~ ACP control 
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When an RSX-llM image issues an ACP request under VAX/VMS, VAX/VMS 
issues an ACP Queue I/O Request system service. It obtains the data 
to fill in the FIB and function-dependent parameters for the request 
from two sources: 

• Function-dependent parameters supplied by the image in the 
QUEUE I/O REQUEST directive 

• Data structures pointed to by function-dependent parameters, 
for example, the file name block 

Once the requested function is performed, VAX/VMS fills in the RSX-llM 
image's data structures with the same information that is returned to 
the image when executing under the RSX-llM operating system. 



5.11.1 General Correspondence of Parameters 

Table 5-14 identifies the relationship of RSX-llM function-dependent 
parameters to VAX/VMS function-dependent parameters and FIB fields. 



Table 5-14 
ACP Parameter Correspondence 



Parameter Function 


RSX-llM Pn 


VAX/VMS Equivalent 


File identification 


PI 


(pointer) 


FIB$W FID (value) 


pointer 








Attribute list pointer 


P2 




P5 (reformatted) 


Extend control 


P3 


(high byte) 


FIB$W_EXCTL 


Delta size in blocks 


P3 


(low byte) and P4 


FIB$L_EXVBN for 
truncate only or 
FIB$L_EXSZ for 
extend 


Window size 


P5 


(low byte) 


FIB$B_WSIZE 


Access control 


P5 


(high byte) 


FIB$L_ACCTL 


File name block pointer 


P6 




P2 (name string) 
and P4 (result 
string) 



5.11.2 lO.CRE Function 

Equivalent Function Code: IO$_CREATE J IO$M_CREATE 

Notes: 

• If the extend size is supplied in the low byte of P3 and in 
P4, it is stored in FIB$L_EXSZ. 
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The high-order byte of P3 (extend control) is used to set bits 
in FIB$W_EXCTL: 

FIB$V_EXTEND = EX.ENA 

FIB$V_ALCON = EX.ACl 

FIB$V_ALCONB = EX.AC2 

FIB$V_FILCON = EX.FCO 

FIB$V_ALDEF = EX.ADF 

The file identification is copied from FIB$W_FID and returned 
in the address pointed to by Pi (FID pointer) . 

Information in the VAX/VMS attribute list is derived from the 
RSX-llM attribute list, if one is supplied. 

The extend size in blocks is returned in bytes 1, 2, and 3 of 
the I/O status block. 



5.11.3 10. DEL with EX.ENA=0 

Equivalent Function Code: IO$_DELETE! I0$M_DELETE 
Note: 

• The file identification pointed to by Pi is copied into 
FIB$W_FID. 

5.11.4 10. DEL with EX.ENA=1 
Equivalent Function Code: I0$_M0DIFY 
Notes: 

• The file identification pointed to by PI is copied into 
FIB$W FID. 



• 



FIB$V_TRUNC is set in field FIB$W_EXCTL. 



• The extend size supplied in the low byte of P3 and in P4 is 
incremented by 1 and stored in FIB$L_EXVBN. 

• The file round-up in blocks is returned in bytes 2 and 3 of 
the I/O status block. File round-up is the number of blocks 
added to the specified file size to reach the next cluster 
boundary. 



5.11.5 lO.ACR Function 

Equivalent Function Code: IO$_ACCESS! IO$M_ACCESS 

Notes: 

• The file identification pointed to by Pi is copied into 
PIB$W FID. 
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• The high byte of P5 (access control) is used to set bits in 
FIB$L_ACCTL: 

FIB$V NOWRITE = AC.LCK 

FIB$V_REWIND = AC . RWD 

FIB$V_CURPOS = AC.POS 

FIB$V_UPDATE = AC.UPD 

• The window size provided by the low byte of P5 is stored in 
FIB$B_WSIZE. 

• Information in the VAX/VMS attribute list is derived from the 
RSX-llM attribute list, if one is supplied. 



5.11.6 lO.ACW and 10. ACE Functions 

Equivalent Function Code: IO$_ACCESS! IO$M_ACCESS 
Notes: 

• The file identification pointed to by PI is copied into 
FIB$W_FID. 

• The high byte of P5 (access control) is used to set bits in 
FIB$L_ACCTL: 

FIB$V_DLOCK = AC.DLK 

FIB$V_NOWRITE = AC.LCK 

FIB$V_REWIND = AC . RWD 

FIB$V_CURPOS = AC.POS 

FIB?V_UPDATE = AC.UPD 

In addition, VAX/VMS sets FIB$V_WRITE. 

• The window size provided by the low byte of P5 is stored in 
FIB$B_WSIZE. 

• Information in the VAX/VMS attribute list is derived from the 
RSX-llM attribute list, if one is supplied. 



5.11.7 lO.DAC Function 

Equivalent Function Code: IO$_DEACCESS 
Notes: 

• The file identification pointed to by Pi is copied into 
FIB$W_FID. 

• Information in the VAX/VMS attribute list is derived from the 
RSX-llM attribute list, if one is supplied. 
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5.11.8 10. EXT Function 

Equivalent Function Code: 10$ MODIFY 

Notes: 

• The file identification pointed to by PI is copied into 
FIB$W_FID. 

• The high byte of P3 (extend control) is used to set bits in 
FIB$W_EXCTL: 

FIB$V_EXTEND = EX.ENA 

FIB$V_ALCON = EX.ACl 

FIB$V_ALCONB = EX.AC2 

FIB$V_FILCON = EX.FCO 

FIB$V_ALDEF = EX.ADF 

• The extend size supplied in the low byte of P3 and in P4 is 
stored in FIB$L_EXSZ. 

• The amount by which the file is extended is returned in bytes 
1, 2, and 3 of the I/O status block. 



5.11.9 10. WAT Function 

Equivalent Function Code: 10$ MODIFY 

Notes: 

• The file identification pointed to by Pi is copied into 
FIB$W_PID. 

• Information in the VAX/VMS attribute list is derived from the 
RSX-llM attribute list, if one is supplied. 



5.11.10 10. RAT Function 

Equivalent Function Code: IO$_ACCESS 

Notes: 

• The file identification pointed to by Pi is copied into 
FIB$W_FID. 

• Information in the VAX/VMS attribute list is derived from the 
RSX-llM attribute list, if one is supplied. 



5.11.11 lO.FNA Function 

Equivalent Function Code: IO$_ACCESS 

Notes: 

• The file identification is copied from FIB$W_FID and returned 
in the address pointed to by Pi. 

• The directory identification is copied from the file name 
block into FIB$W_DID. 
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• The file name string supplied in the request is constructed 
from the Radix-50 file name in the file name block. 

• If the bit NB.WLV is set in N.STAT of the file name block, a 
resultant string is constructed from the Radix-50 name and 
type. The version number is stored in N.FID+4 of the name 
block, and is supplied as input to the IO$_ACCESS call. 

If NB.WLV is not set, a resultant string of zero length is 
supplied . 

• The file name string returned is the resultant string returned 
by the Queue I/O Request system service. It is converted back 
to Radix-50 and returned to the file name block. 

• Control bits in field N.STAT of the file name block are used 
to set bits of FIB$W_NMCTL: 

FIB$V_ALLNAM = NB.SNM 

FIB$V_ALLTYP = NB . STP 

FIB$V_ALLVER = NB.SVR 

FIB$V_WILD = NB.SNMINB. STP! NB.SVR 

• The file name block field N.NEXT is used to set FIB$L_WCC. 
The resulting value of FIB$L_WCC is returned in N.NEXT. 



5.11.12 lO.RNA Function 

Equivalent Function Code: IO$_DELETE 

Notes: 

• The file identification is copied from FIB$W_FID and returned 
in the address pointed to by Pi. 

• The directory identification is copied from the file name 
block into FIB$W_DID. 

• If the bit NB.WLV is set in N.STAT of the file name block, a 
resultant string is constructed from the Radix-50 name and 
type. The version number is stored in N.FID+4 of the name 
block, and is supplied as input to the IO$_ACCESS call. 

If NB.WLV is not set, a resultant string of zero length is 
supplied. 

• The file name string supplied in the request is constructed 
from the Radix-50 file name in the file name block. - 

• The file name returned is the resultant string returned by the 
Queue I/O Request system service. It is converted back to 
Radix-50 and returned to the file name block. 

• Control bits in field N.STAT of the file name block are used 
to set bits of FIB$W_NMCTL: 

FIB$V_ALLNAM = NB.SNM 

FIB$V_ALLTYP = NB.STP 

FIB$V_ALLVER = NB.SVR 

FIB$V_WILD = NB.SNM! NB.STP 'NB.SVR 

• The file name block field N.NEXT is used to set FIB$L_WCC. 
The resulting value of FIB$L_WCC is returned in N.NEXT. 
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5.11.13 lO.ENA Function 

Equivalent Function Code: IO$_CREATE 

Notes: 

• The file identification is copied from the file name block 
into FIB$W_FID. 

• The directory identification is copied from the file name 
block into FIB$W_DID. 

• The file name string supplied in the request is constructed 
from the Radix-50 file name in the file name block. 

• The file name returned is the resultant string returned by the 
Queue I/O Request system service. It is converted back to 
Radix-50 and returned to the file name block. 



5.11.14 10. ARC Function 

Equivalent Function Code: I0$_ACPC0NTR0L 

Notes: 

• P3 contains the subfunction identification. The low-order 
byte of P3 is zero-extended and stored at FIB$W_CNTRLFUNC, 
which overlays FIB$W_EXCTL. The RSX-llM ACP subfunction codes 
have direct equivalents in VAX/VMS, as follows. 

RSX-llM Subfunction VAX/VMS Subfunction 

FF.NV FIB$C_NEXTVOL 

FF.POE FIB$C_POSEND 

FF.RWD FIB$C_REWINDVOL 

FF.RWP FIB$C_REWINDFIL 

FF.SPC FIB$C_SPACE 

• For the FF.SPC subfunction, P4 is sign-extended and stored at 
FIB$L_CNTRLVAL, which overlays FIB$L_EXSZ. A negative value 
for P4 specifies the number of blocks to space backward. A 
positive value indicates the number of blocks to space 
forward . 
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APPENDIX A 
VAX-11/780 COMPATIBILITY MODE INSTRUCTION SET 

Table A-1 lists the compatibility mode instruction set on VAX-11/780. 



Table A-1 
VAX-11/780 Compatibility Mode Instruction Set 



Opcode 


Mnemonic 


(octal) 




000002 


RTI 


000006 


RTT 


OOOIDD 


JMP 


00020R 


RTS 


000240-000277 


Condition codes 


0003DD 


SWAB 


000400-003777 


Branches 


100000-103777 


Branches 


004RDD 


JSR 


.050DD 


CLR(B) 


.051DD 


COM(B) 


.052DD 


INC(B) 


.053DD 


DEC{B) 


.054DD 


NEG(B) 


.055DD 


ADC (B) 


.056DD 


SBC(B) 


.057DD 


TST(B). 


.060DD 


RCR(B) 


.061DD 


ROL(B) 


.062DD 


ASR(B) 


.063DD 


ASL(B) 


0065SS 


MFPI (See note below.) 


0066DD 


MTPI (See note below.) 


1065SS 


MFPD (See note below.) 


1066DD 


MTPD (See note below.) 


0067DD 


SXT 


070RSS 


MUL 


071RSS 


DIV 


072RSS 


ASH 


073RSS 


ASHC 


074RSS 


XOR 


077RNN 


SOB 


.ISSDD 


MOV(B) 


.2SSDD 


CMP(B) 


.3SSDD 


BIT(B) 


.4SSDD 


BIC(B) 


.5SSDD 


BIS(B) 


06SSDD 


ADD 


16SSDD 


SUB 
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NOTE 

The MFPI, MTPI, MFPD, and MTPD, 
instructions execute exactly as they 
would on a PDP-11 in user mode with 
Instruction and Data space overmapped. 
More specifically, they ignore the 
previous access level and act like PUSH 
and POP instructions referring to the 
current stack. 

VAX/VMS provides emulation of the FPP floating point instructions. 
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APPENDIX B 
PARSE DIRECTIVE 



The parse directive allows an RSX-llM image to use VAX/VMS file 
specifications that are not fully qualified because of the use of 
logical names. Use of this directive replaces the operation of the 
FCS .PARSE, .PRSDR, and .PRSDV routines and the RMS-11 $PARSE routine 
for RSX-llM images running in VAX/VMS. 

An RSX-llM image requests the parsing of a file specification by 
issuing a parse directive that supplies the addresses of a file name 
block and data structures containing default information. VAX/VMS 
uses the information supplied by the image and information contained 
in the RSX-llM logical name table and the system logical name table to 
build the primary and default strings that VAX-ll RMS requires to 
perform the actual parsing. VAX-ll RMS returns the expanded name to 
VAX/VMS. VAX/VMS, in turn, uses the expanded name to fill in the 
appropriate RSX-llM data structures, for example, returned directory 
string and file name block. The result is that the image receives the 
information in the normal RSX-llM formats. 

The image can request four different types of parsing: 

• Parsing of the full file specification (normal mode) 

• Parsing of the device name only (device-only mode) 

• Parsing of the file name using the default file name block as 
the major source of input (dfnb mode) 

• RMS-11 mode of parsing 



B.l NORMAL MODE PARSING 

When the mode parameter is equal to 0, VAX-ll RMS parses the full file 
specification. VAX/VMS builds the primary string required as input to 
VAX-ll RMS by concatenating fields of the dataset descriptor, as 
follows: 

• Device 

• Directory 

• Filename. type ;version 

It builds the default string from fields of the default file name 
block and from the default directory descriptor, as follows: 

• Device from the LUN or default file name block 
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• Default directory from the image's default directory 
descriptor 

• Filename. type;version from the default file name block 

VAX-11 RMS returns to the RSX-llM image a filled-in file name block 
and directory str ing, descriptor in the file name block. The directory 
string is returned at the address specified in the descriptor. 



B.2 DEVICE-ONLY PARSING 

When the mode parameter is equal to 1, VAX-11 RMS parses only the 
device and directory portion of the file specification. It uses the 
same sources for the primary and default strings as it does for a 
normal parsing operation. 



B.3 DEFAULT FILENAME BLOCK PARSING 

When the mode parameter is equal to 2, VAX/VMS uses the Radix-50 file 
name in the default file name block to build the ASCII file name for 
the primary string. 

For the default string, VAX/VMS takes the device name from the default 
file name block. It takes the directory name from the default 
directory descriptor, and the file name, type, and version from the 
default file name block. 

The DSW return codes for default file name block parsing are the same 
as for normal mode parsing. 



B.4 RMS-11 MODE OF PARSING 

When the mode parameter is equal to 3, VAX-11 RMS parses the file 
specification using the same method used by RMS-11. The format for 
the DPB is slightly different from that used for modes 0, 1, and 2, as 
described below. 



B.5 DIRECTIVE CALL AND DPB FORMATS 

The parse directive is called using DIR$, as follows: 

DIR$ tpardpb 

The DPB has the following format for modes 0, 1, and 2. 

pardpb: .BYTE 145., 7 

.WORD mode 

. WORD 1 un 

•WORD dspt 

.WORD dfnb 

.WORD dfdd 

.WORD fnb 

.WORD rtdd 
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BYTE 


145. ,7 


WORD 


mode 


WORD 


lun 


WORD 


pript 


WORD 


did 


WORD 





WORD 


fnb 


WORD 


expnam 



PARSE DIRECTIVE 

mode = for normal mode, 1 for parsing device only, 2 for 
parsing using default file name block, or 3 for 
RMS-11 mode. See the sections that follow for a 
description. 

lun = logical unit number. 

dspt = address of the data set descriptor. 

dfnb = address of the default name block. 

dfdd = address of the descriptor for the default directory 
string. See the first note below. 

fnb = address of the file name block. 

rtdd = address of the descriptor for the returned directory 
string. See the first note below. 

The DPB has the following format for mode 3. 

pardpb: 



;this word is ignored. 



The definitions of mode, lun, and fnb are the same as those for the 
DPB format provided above. 

pript = address of the primary input descriptor. 

did = address of the default input descriptor. 

expnam = address of the descriptor for the block in which 
to return the expanded name. 

DSW Return Codes: 

IS. sue — Success 

IE. BAD — Invalid mode missing or bad parameter (default error) 

lE.NSF — Directory not found (RMS$_DNF) 

lE.BDI — Bad directory syntax (RMS$_DIR) 

lE.BNM — Bad file name (RMS$_(SYN,FNM,LNE,TYP,VER) ) 

lE.DNR — Device not ready (RMS$_DNR) 

IE. DUN — Device not available (RMS$_CHN) 

lE.NSF — File not found (RMS$_FNF) 

lE.BDV — Bad device specification {RMS$ DEV) 



• All descriptor input parameters must be a 2-word block with 
the following format. 

.WORD size 
•WORD address 

• RSX-llM does not support this directive. An RSX-llM image 
using this directive can test for an illegal directive DSW 
code to determine whether it is executing under RSX-llM or 
VAX/VMS and take appropriate action at run time. 
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Abnormal image termination, 

2-11 
Abnormal termination of RSX-llM 

images, 2-11 
ABORT TASK directive, 2-3, 4-8 
ABRT$ directive, 4-8 
ALLOCATE command, 5-2 
Allocate Device system service, 

3-4 
Allocation, 5-2 
implicit, 5-2 

ALTER PRIORITY directive, 2-8, 

4-9 
ALTP$ directive, 4-9 
ALUN$ directive, 4-10 
Ancillary control processes 

(ACPs), 3-4, 5-24 
functions, 3-11 
Assign I/O Channel system 

service, 3-3, 4-10 
emulation of ASSIGN LUN 

directive, 4-10 
ASSIGN LUN directive, 2-14, 

3-6, 4-10 
Assignment of devices, 3-6 
AST SERVICE EXIT directive, 

4-11 
ASTX$ directive, 4-11 
Attach I/O device (10. ATT) , 

5-2 
ATTACH REGION directive, 4-6 



B 

Balance set swapping, 2-7 



Cancel Wakeup system service, 

4-14 
emulation of CANCEL TIME 

BASED INITIATION REQUESTS 

directive, 4-14 
Channel, 3-3 
Characteristics bit handling, 

5-8 
magnetic tape, 5-8 
terminal ( SF . GMC and SF . SMC ) , 

5-20 
CL, 3-6 

assignment of, 3-6, 3-8 
CLEAR EVENT FLAG directive, 

4-12 
CLEAR EVENT FLAG system 

service, 4-12 
emulation of CLEAR EVENT 

FLAG directive, 4-12 
CLEF$ directive, 4-12 
Clock, system, 2-8 
CMKT$ directive, 4-13 
CO, 

assignment of, 3-6, 3-8 
COMMON, 2-9 
Common areas, 2-9 
Compatibility mode instruction 

set, 1-1, A-1 
Condition handling, 2-11 
Control region, 1-5 
CREATE ADDRESS WINDOW directive, 

4-6 
Create and Map Section system 

service, 2-9 
Create Mailbox and Assign I/O 

Channel system service, 

3-3 
CREATE REGION directive, 4-6 
CSRQ$ directive, 4-14 



Cancel I/O on Channel system 

service, 3-4, 5-3 
Cancel I/O request (lO.KIL), 

5-3 
CANCEL MARK TIME REQUESTS 

directive, 4-13 
CANCEL TIME BASED INITIATION 

REQUESTS directive, 2-3, 

4-14 
Cancel Timer Request system 

service, 4-13 
emulation of CANCEL MARK 

TIME REQUESTS directive, 4-13 



DECL$ directive, 4-15 
DECLARE SIGNIFICANT EVENT 

directive, 2-8, 4-15 
Detach I/O device (lO.DET), 

5-2 
DETACH REGION directive, 4-6 
Device allocation, 3-4 
Device assignment, 3-6, 4-10 

CL, 3-6, 3-8 

CO, 3-6, 3-8 

TI, 3-6, 3-8 
Device attachment, 3-4 
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Device name mapping, 3-8 
ASSIGN LUN directive, 4-10 
GET LUN information directive, 

4-25 
LB, 3-8 
OV, 3-8 
SP, 3-8 
SY, 3-8 
WK, 3-8 
Device-independent I/O, 3-1 
Devices supported, 5-2 
Devices, 5-2 

shareable, 5-2 
Directives, 4-8 
ABORT TASK, 4-8 
ALTER PRIORITY, 2-8, 4-9 
ASSIGN LUN, 2-14, 3-6, 4-10 
AST SERVICE EXIT, 4-11 
ATTACH REGION, 4-6 
CANCEL MARK TIME REQUESTS, 

4-13 
CANCEL TIME BASED INITIATION 

REQUESTS, 4-14 
CLEAR EVENT FLAG, 4-12 
CONNECT TO INTERRUPT VECTOR, 

4-6 
CREATE ADDRESS WINDOW, 4-6 
CREATE REGION, 4-6 
DECLARE SIGNIFICANT EVENT, 

2-8, 4-15 
DETACH REGION, 4-6 
DISABLE AST RECOGNITION, 4-16 
DISABLE CHECKPOINTING, 2-7, 

4-17 
ELIMINATE ADDRESS WINDOW, 

4-6 
emulation of, 1-3 
ENABLE AST RECOGNITION, 4-18 
ENABLE CHECKPOINTING, 2-7, 

4-19 
event-associated, summary of, 

4-3 
EXIT IF, 4-20 
EXIT WITH STATUS, 4-22 
EXTEND TASK, 4-2 3 
GET LUN INFORMATION, 2-14, 

3-4, 4-24, 5-2 
GET MAPPING CONTEXT, 4-6 
GET MCR COMMAND LINE, 4-26 
GET PARTITION PARAMETERS, 

2-7, 4-28 
GET REGION PARAMETERS, 4-6 
GET SENSE SWITCHES, 4-6 
GET TASK PARAMETERS, 2-2, 

4-30 
GET TIME PARAMETERS, 2-8, 

4-29 
I/O, summary of, 4-5 
informational, summary of, 
4-2 



Directives (Cont. ) , 

INHIBIT AST RECOGNITION, 

4-16 
interprocess communications, 

sximmary of, 4-5 
MAP ADDRESS WINDOW, 4-6 
MARK TIME, 2-8, 4-31 
QUEUE I/O REQUEST, 2-14, 3-4, 

3-11, 4-33, 5-1, 5-3 
QUEUE I/O REQUEST AND WAIT, 

2-14, 4-35 
READ ALL EVENT FLAGS, 4-38 
RECEIVE DATA, 2-14, 3-9, 

4-36 
RECEIVE DATA OR EXIT, 2-14, 

3-9, 4-37 
REQUEST, 2-10, 4-39 
RESUME, 2-10, 4-40 
RUN, 2-8, 2-10, 4-41 
SEND DATA, 2-14, 3-9, 3-11, 

4-43 
SET EVENT FLAG, 4-44 
SPECIFY FLOATING POINT 

PROCESSOR EXCEPTION AST, 

4-45 
SPECIFY POWER RECOVERY 

AST, 4-47 
SPECIFY RECEIVE DATA AST, 

4-48 
SPECIFY RECEIVE-BY- REFERENCE 

AST, 4-6 
SPECIFY SST VECTOR TABLE 

FOR DEBUGGING AID, 4-50 
SPECIFY SST VECTOR TABLE 

FOR TASK, 4-51 
SUSPEND, 4-46 
task execution control, 

summary of, 4-5 
TASK EXIT, 2-10, 4-21 
trap-associated, summary of, 

4-4 
UNMAP ADDRESS WINDOW, 4-6 
unsupported, 4-6 
use restricted by protection, 

2-2 
WAIT FOR LOGICAL OR EVENT 

FLAGS, 4-53 
WAIT FOR SIGNIFICANT EVENT, 

2-8, 4-52 
WAIT FOR SINGLE EVENT FLAG, 

4-54 
DISABLE AST RECOGNITION 

directive, 4-16 
DISABLE CHECKPOINTING directive, 

2-7, 4-17 
Disk driver, 5-7 
10. ATT, 5-7 
lO.DET, 5-7 
lO.KIL, 5-7 
lO.LOV, 5-7 
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Disk driver (Cont.), 

lO.RLB, 5-7 

lO.RPB, 5-7 

lO.RVB, 5-7 

lO.WDD, 5-7 

lO.WLB, 5-7 

lO.WPB, 5-7 

lO.WVB, 5-7 
Drivers, 5-7 

card reader, 5-22 

disk, 5-7 

line printer, 5-10 

magnetic tape, 5-10 

null device, 5-23 
DSAR$ directive, 4-16 
DSCP$ directive, 4-17 
DSW return codes, 2-6, 4-7 



FCS (file control services), 

3-1, 3-6 
FCS spooling, 3-11 
File identification block, 

5-25 
format, 5-25 
Floating point instructions, 

emulation of, 1-4 
Force Exit system service, 
emulation of ABORT TASK 

directive, 4-8 
Formula for physical device 

name mapping, 3-7 
Function codes, 

see I/O function codes 
Function-dependent parameters , 

5-1 



ELIMINATE ADDRESS WINDOW 

directive, 4-6 
Emulation of directives, 1-3 
Emulation of floating point 

instructions, 1-4 
ENABLE AST RECOGNITION 

directive, 4-18 
ENABLE CHECKPOINTING directive, 

2-7, 4-19 
ENAR$ directive, 4-18 
ENCP$ directive, 4-19 
Error codes, 

see DSW return codes 
Error status returns (lOSB) , 

5-3 
Event flag clusters, 2-4 
common, 2-4 
local, 2-4 
protected by group number, 

2-4 
Event-associated directives, 

4-3 
EX$ERR (error) , 4-22 
EX$SEV (severe error) , 4-22 
EX$SUC (normal) , 4-22 
EX$WAR (warning) , 4-22 
EXIF$ directive, 4-20 
EXIT IF directive, 4-20 
Exit system service, 4-20 
emulation of, 

EXIT IF directive, 4-2 

RECEIVE DATA OR EXIT 
directive, 4-37 

TASK EXIT directive, 4-21 
EXIT WITH STATUS directive, 4-22 
EXIT$ directive, 4-21 
EXTEND TASK directive, 4-23 



GEN partition, 4-28 

GET PARTITION PARAMETERS, 

4-28 
GET TASK PARAMETERS, 4-30 
Get Channel Information system 

service, 3-4, 4-25 
emulation of GET LUN 

INFORMATION directive, 4-25 
GET LUN INFORMATION directive, 

2-14, 3-4, 4-24 
GET MAPPING CONTEXT directive, 

4-6 
GET MCR COMMAND LINE directive, 

4-26 
GET PARTITION PARAMETERS 

directive, 2-7, 4-2 8 
GET REGION PARAMETERS direc- 
tive, 4-6 
GET SENSE SWITCHES directive, 

4-6 
GET TASK PARAMETERS directive, 

2-2, 4-30 
GET TIME PARAMETERS directive, 

2-8, 4-29 
Global sections, 2-9 
permanent, 2-9 
protection by group, 2-9 
temporary, 2-9 
use for commons and libraries, 

2-9 
GLUN$ directive, 4-24 
GMCR$ directive, 4-26 
GPRT$ directive, 4-28 
GTIM$ directive, 4-29 
GTSK$ directive, 4-30 
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H 

HALT instruction, 1-2 
Hibernation, 2-10 



I 



I/O channel, 3-3 
I/O directives, 4-5 
I/O drivers, 3-4, 5-1 
I/O function codes (standard) , 
5-2 

10. ATT, 5-2 

lO.DET, 5-2 

lO.KIL, 5-3 
I/O status block, 3-4, 3-6, 

5-3 
I/O status returns, 5-4 

summary of, 5-4 
I/O system, 2-14 
I/O system services, 3-2 
Image termination, 2-10 
Image, 1-4 

concept of, 1-4 
Implicit device allocation, 

5-2 
Informational directives, 4-2 
INHIBIT AST RECOGNITION, 4-16 
Instruction set, 1-1 

compatibility mode, A-1 
Interprocess communications 
directives, 4-5 

summary of, 4-5 
10. ACE (ACP) , 5-28 
lO.ACR (ACP), 5-27 
lO.ACW (ACP), 5-28 
lO.APC (ACP), 5-31 
10. ATA, 5-15 

terminal, 5-15 
10. ATT, 5-2 

disk, 5-7 

line printer, 5-10 

magnetic tape, 5-8 

terminal, 5-15 
lO.CCO (terminal), 5-18 
lO.CRE (ACP), 5-26 
lO.DAC (ACP), 5-28 
10. DEL (ACP), 5-27 
lO.DET, 5-2 

disk, 5-7 

line printer, 5-10 

magnetic tape, 5-8 

terminal, 5-15 
lO.ENA (ACP), 5-31 
10. EOF (magnetic tape), 5-8 
lO.FNA, 5-29 
10. GTS (terminal), 5-19 



lO.KIL, 3-4, 5-3 

disk, 5-7 

line printer, 5-10 

magnetic tape, 5-8 
lO.LOV (disk), 5-7 
lO.RAL (terminal), 5-16 
10. RAT (ACP), 5-29 
lO.RLB, 

disk, 5-7 

magnetic tape, 5-8 

terminal, 5-16 
lO.RLV (magnetic tape), 5-8 
lO.RNA (ACP) , 5-30 
lO.RNE (terminal), 5-17 
lO.RPB, 

disk, 5-7 

terminal, 5-18 
,10. RPR (terminal), 5-17 
lO.RST (terminal), 5-17 
lO.RVB, 

disk, 5-7 

magnetic tape, 5-8 

terminal, 5-18 
lO.RWD (magnetic tape) , 5-8 
lO.RWU (magnetic tape), 5-8 
10. SEC (magnetic tape), 5-8 
lO.SMO (magnetic tape), 5-8 
lO.SPB (magnetic tape), 5-8 
10. SPF (magnetic tape), 5-8 
10. STC (magnetic tape), 5-8 
lO.WAL (terminal), 5-18 
10. WAT (ACP), 5-29 
lO.WBT (terminal), 5-18 
lO.WDD (disk) , 5-7 
lO.WLB, 

disk, 5-7 

line printer, 5-10 

magnetic tape, 5-8 

terminal, 5-18 
lO.WPB (disk) , 5-7 
lO.WVB, 

disk, 5-7 

line printer, 5-10 

magnetic tape, 5-r8 

terminal, 5-18 
lOSB status returns, 5-3 



LIBR, 2-9 
Libraries, 2-9 
Limits, 2-2 

resource use, 2-2 
Line printer driver, 5-10 
Logical devices, 3-3 

SyS$COMMAND, 3-3 

SYS$ERROR, 3-3 
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Logical devices (Cont.) , 
SYS$INPUT, 3-3 
SYS$LIBRARY used with 
commons and libraries, 
2-9 
SYS$OUTPUT, 3-3 
Logical names for mailboxes, 3-10 

M 

Magnetic tape, 5-8 
characteristics bit 

handling, 5-8 
driver, 5-8 
Mailbox creation, 3-10 
Mailbox name for send/receive, 

3-9 
Mailbox unit numbers, 3-10 
Mailboxes, 3-3, 3-9 

deleted during TASK EXIT, 

4-21 
use for RECEIVE DATA 

directive, 4-36 
use for RECEIVE DATA OR EXIT 

directive, 4-37 
use for SEND DATA directive, 
4-43 
MAP ADDRESS WINDOW directive, 

4-6 
Map Global Section system 

service, 2-9 
MARK TIME directive, 2-8, 4-31 
MCR (DCL) Command, 4-26 
GET MCR COMMAND LINE 
directive, 4-26 
Memory management, 2-7 
MRKT$ directive, 4-31 
Multiuser MCR tasks, 2-3 

naming of, 2-3 
Multiuser task images, 1-4 

N 

Names, 2-3 

process, 2-3 
Native mode considerations, 
2-5 

2-5 
process name, 2-4 

o 

ON command, 2-11 
.ONERR, 2-11 
Overlays, 1-4 



Paging, 2-7 
Parameters , 

fimction-dependent, 5-1 
function-independent, 5-1 
Parsing file specifications, 
2-14 
directive for, 2-14, B-1 
Partitions, 
GEN, 2-7 
lack of, 2-7 
Physical device name conver- 
sion, 3-7 
Physical devices supported, 

5-2 
PLAS (nonsupport) , 1-4, 2-7 
PRINT$, 3-11 
Priorities, 2-8 
Privilege, 2-1 

use with UIC, 2-1 
Privileged instructions, 1-2 
HALT, 1-2 
RESET, 1-2 
Process control directives, 4-1 
Process names, 2-3 

qualified by UIC, 2-3 
Process privileges, 2-1 
Process, 1-4 

concept of, 1-4 
detached, 2-10 
subprocess, 2-10 
virtual address space of, 
1-5 
Process-permanent files, 3-3 
Protection, 4-8 
by group number, 

use with SEND DATA, 4-43 
use with RECEIVE DATA, 

4-36 
use with RECEIVE DATA OR 
EXIT, 4-37 
by group number and privilege, 
use with ABORT TASK, 4-8 
use with CANCEL TIME BASED 

INITIATION REQUESTS, 4-14 
use with REQUEST, 4-39 



USB wxuii rvciOUi'iCi, 



use with RUN, 4-41 
by privilege, 

use with DISABLE CHECK- 
POINTING, 4-17 
use with ENABLE CHECK- 
POINTING, 4-19 
UlC-based, 2-1 
PRT... task, 3-11 
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Q 

QIO$ directive, 4-33 
QIOW$ directive, 4-35 
QUEUE I/O REQUEST AND WAIT 

directive, 2-14, 4-35 
Queu^ I/O Request and Wait 
for Event Flag system 
service, 4-35 
emulation of QUEUE I/O 
REQUEST AND WAIT, 4-35 
QUEUE I/O REQUEST directive, 
2-14, 3-4, 3-11, 4-33, 
5-1, 5-3 
Queue I/O Request system 
service, 4-33 
emulation of, 

QUEUE I/O REQUEST 
directive, 4-33 
RECEIVE DATA, 4-36 
RECEIVE DATA OR EXIT 

directive, 4-37 
SEND DATA directive, 
4-43 



RCVD$ directive, 4-36 
RCVDname mailbox, 3-9 

RECEIVE DATA directive, 4-36 
RECEIVE DATA OR EXIT 

directive, 4-37 
SEND DATA directive, 4-43 
RCVX$ directive, 4-37 
RDAF$ directive, 4-38 
READ ALL EVENT FLAGS, 4-38 
Read Event Flags system service, 
emulation of, 

EXIT IF directive, 4-20 
READ ALL EVENT FLAGS 
directive, 4-38 
Reasons for termination, 2-13 
RECEIVE BY REFERENCE directive, 

4-6 
RECEIVE DATA directive, 2-14, 

3-9, 4-36 
RECEIVE DATA OR EXIT directive, 

2-14, 3-9, 4-37 
REQUEST directive, 2-3, 2-10, 

4-39 
RESCOM, 2-9 
RESET instruction, 1-2 
Resident libraries, 2-9 
RESLIB, 2-9 

Resource use limits, 2-2 
Resource wait mode, 2-3 



Restrictions, 
hardware, 1-2 
software, 1-2 
RESUME directive, 2-3, 2-10, 

4-40 
Resume Process system service, 
4-40 
emulation of the RESUME 
directive, 4-40 
Return codes, 

see DSW return codes 
RMS-11, 3-1, 3-6 
RQST$ directive, 4-39 
RSUM$ directive, 4-40 
RSXCOMEFN event flag cluster, 

2-4, 2-6, 4-21 
RUN directive, 2-3, 2-8, 
2-10, 4-41 



Schedule Wakeup system 
service, 4-41 
emulation of RUN directive, 
4-41 
SDAT$ directive, 4-43 
SEND DATA directive, 2-3, 
2-14, 3-9, 3-11, 4-43 
Set AST Enable system 
service, 4-16 
emulation of, 

DISABLE AST RECOGNITION 

directive, 4-16 
ENABLE AST RECOGNITION 

directive, 4-18 
SPECIFY RECEIVE DATA AST 
directive, 4-48 
SET EVENT FLAG directive, 4-44 
Set Event Flag service, 4-44 
emulation of SET EVENT FLAG 
directive, 4-44 
Set Swap Mode system service, 
emulation of, 

DISABLE AST RECOGNITION 

directive, 4-16 
ENABLE CHECKPOINTING 
directive, 4-19 
Set Timer system service, 4-31 
emulation of MARK TIME 
directive, 4-31 
SETF$ directive, 4-44 
SF.GMC (terminal), 5-20 
SF.SMC (terminal), 5-20 
Shareable devices, 5-2 
Shareable regions, 1-4 
Shareable task images, 1-4 
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Significant events, 2-8 
Software priorities, 2-8 
SPECIFY FLOATING POINT PROCESSOR 

EXCEPTION AST, 4-45 
SPECIFY POWER RECOVERY AST 

directive, 4-47 
SPECIFY RECEIVE DATA AST 

directive, 4-48 
SPECIFY RECEIVE-BY-REFERENCE 

directive, 4-6 
SPECIFY SST VECTOR TABLE FOR 
DEBUGGING AID directive, 
4-50 
SPECIFY SST VECTOR TABLE FOR 

TASK directive, 4-51 
SPND$ directive, 4-46 
Spooling, 3-11, 5-10, 5-21 
SPRA$ directive, 4-47 
SRDA$ directive, 4-48 
Standard I/O function codes, 

5-2 
Status returns (lOSB) , 5-3 

terminal read, 5-20 
Subf unction modifiers, 5-1 
Subprocess, 2-10 
SUSPEND directive, 4-46 
Suspend Process system service, 
4-46 
emulation of SUSPEND direc- 
tive, 4-46 
SVDB$ directive, 4-50 
SVTK$ directive, 4-51 
Swapping, 2-7 
Synchronous system trap (SST) , 

2-11 
SYS$COMMAND, 3-3, 3-8, 5-21 
SYS$DISK, 3-8 
SYS$ERROR, 3-3, 3-8, 5-21 
SYS$INPUT, 3-3, 3-8, 5-21 
SYS$LIBRARY, 2-9 
SYS$OUTPUT, 3-3, 3-8, 5-21 
System clock, 2-8 
System events, 2-8 
System service, 5-3 

Cancel I/O on Channel, 5-3 
System status codes, 2-6 

mapping to DSW return codes. 



TASK EXIT directive, 2-10, 4-21 
Task image label block, 2-3 
Task name, 

see Process name 
Terminal characteristics bit 

handling, 5-20 
Terminal driver, 5-12 



Terminal read status returns, 

5-20 
Termination, 

abnormal, 2-11 

normal, 2-10 
Termination code, 2-10 
Termination status, 2-10 
TI, 3-6 
TI, CO, and CL, 

assignment of, 3-8 
Trap instructions, 2-11 
Trap-associated directives, 4-4 

u 

UIC based protection, 2-1 
UIC, 2-1 

format for VAX/VMS, 2-1 

parsing, 2-2 

returned for GET TASK PARAM- 
ETERS, 2-2 
UNMAP ADDRESS WINDOW directive. 

4-6 
Unsupported directives, 4-6 
User authorization file, 2-1 

resource use limits, 2-2 



VAX-11 RMS, 3-1 
VAX-11 RMS, 3-3 

use with process-permanent 
files, 3-3 
VAX/VMS system concepts, 1-4 

image, 1-4 

process, 1-4 
Virtual address space, 1-5 

control region, 1-5 

lack of PLAS support, 2-7 

management of, 2-7 

paging, 2-7 

program region, 1-5 

w 

WAIT FOR LOGICAL OR OF EVENT 

FLAGS directive, 4-53 
Wait for Logical OR of Event 
Flags system service, 4-53 
emulation of, 

WAIT FOR LOGICAL OR OF 

EVENT FLAGS, 4-53 
WAIT FOR SINGLE EVENT FLAG, 
4-54 
WAIT FOR SIGNIFICANT EVENT 
directive, 2-8, 4-52 
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WAIT FOR SINGLE EVENT FLAG 
directive, 4-54 

Wake system service, 2-10 
emulation of REQUEST direc- 
tive, 2-10, 4-39 



Working set, 2-7 

WSIG$ directive, 4-52 

WTLO$ directive, 4-53 

WTSE$ directive, 4-54 
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READER'S COMMENTS 



NOTE: This form is for docvunent comments only. DIGITAL will 
use comments submitted on this form at the company's 
discretion. Problems with software should be reported 
on a Software Performance Report (SPR) form. If you 
require a written reply and are eligible to receive 
one under SPR service, submit your comments on an SPR 
form. 

Did you find errors in this manual? If so, specify by page. 



Did you find this manual understandable, usable, and well-organized? 
« Please make suggestions for improvement. 



c 
o 



3 

u 



Is there sufficient documentation on associated system programs 
required for use of the software described in this manual? If not, 
what material is missing and where should it be placed? 



Please indicate the type of user /reader that you most nearly represent. 

Q Assembly language programmer 

I I Higher-level language programmer 

I I Occasional programmer (experienced) 

I I User with littTp proaramminrr exi^erienCS 

I I Student programmer 

Q Non-programmer interested in computer concepts and capabilities 

Name ____^ Date 

Organization . 

Street . 



City State zip Code. 

or 
Country 
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